IT Picnic · August 8, 2026
State of AI4SDLC: How AI Shifts Bottlenecks Across Software Delivery
Coding accelerates first. Delivery follows only when the whole flow changes.
/ State of AI4SDLC · IT Picnic 2026
Slide contents
1. State of AI4SDLC: How AI Shifts Bottlenecks Across Software Delivery
Coding accelerates first. Delivery follows only when the whole flow changes.
2. The bottleneck moves
A local coding speedup creates a queue downstream
3. 01. Coding speeds up first
AI removes a local constraint and exposes the next stage
4. AI is no longer an IDE experiment
Manage changed development physics
default tool — Mass adoption — AI writes code, tests, docs, explanations.
task-dependent — Uneven effect — Coding speeds up before delivery.
verify-first — Management question — Manage adoption, throughput, quality/risk, economics.
5. How we know what is happening
Industry reports and AI4SDLC point the same way
Industry research
DORA and AI-assisted development reports.
Big tech cases: Google, Microsoft, GitHub, Meta, Uber.
AI4SDLC research
50+ studies from 2023–2025.
Survey of engineers and leads.
6. Adoption is high, trust is lower
Signals repeat across studies
Everyday tool — AI is part of the workday.
Uneven productivity — The effect depends on tasks and process maturity.
Delivery lags — Reviews, tests and evals are mandatory.
7. Coding is faster. Delivery isn't
The queue moves to review, tests, and intent
More WIP before review
Tests absorb more changes
Weak intent scales the error
Verification becomes the constraint
8. Role-based SDLC and agent-based SDLC
In SE 2.0 the human writes fewer lines and manages intent, context, and verification more
Software Engineering 1.0 (Role-based SDLC)
Idea
Req
Dev
Test
Deploy
Support
Product
Analyst
Developer
QA Engineer
SRE
Support Engineer
Losses on work handoffs
AI scenarios inside roles
Local optimizations
On brownfield projects we run AI scenarios per role
Software Engineering 2.0 (Agent-based SDLC)
Idea
Req
Dev
Test
Deploy
Support
Product
Engineer
Support Engineer
Fewer losses on handoffs
Faster e2e scenarios
On greenfield projects we try agent-based development
Carrying over scenario learnings
Carrying over scenario learnings
Further reading: https://tellmeabout.tech/from-classic-pdlc-to-ai-native-2f03c56e1777
9. Specs return: interface for agents
Human-agent contract
Agents need intent, boundaries, acceptance criteria.
Tools exist: Spec Kit, OpenSpec, SDD.
Specs connect to tasks, tests, review.
Bad specs only scale mistakes.
V Model
10. 02. The constraint becomes systemic
The platform expands throughput without losing control
11. Scale dictates the requirements
10,000+ engineers need a platform
10,000+ — Scale — Thousands of services, repositories, and stacks.
fintech — Security — Data, secrets, and PII require a control perimeter.
unit economics — Economics — Token and infra costs are company-level.
12. North Star: three axes
Each axis needs baseline, guardrails, and owner
speed — Speed — Lead time and cycle time to production.
quality — Quality — Defects, incidents, rollbacks, security findings.
economics — Economics — Token, infra, and human-time costs.
13. IDP lives; GUI fades
Control stays platform-side
To agent
User intent and next action.
IDE, wiki, CI/CD, observability.
Natural language for capabilities.
Platform
Domain logic, policies, state changes.
Limits, quotas, cost, and blast radius.
GUI: settings, investigations, approvals.
Article: https://tellmeabout.tech/is-idp-dead-no-the-gui-monopoly-is-dying-331c72ae4d03
14. Three layers of an agent-first platform
Model gateway, tool/MCP gateway, and capability registry solve different problems and do not replace one another
01. Model gateway
AI / model gateway
The layer between your code and LLM providers.
Not a tool catalog or registry.
Apps / agents
LLM requests
Gateway
auth · quotas · cache · cost · PII
LLM API
model providers
LiteLLM Proxy · Envoy AI Gateway
Uber GenAI Gateway
02. Tool gateway
tool / MCP gateway
The layer between agents and platform capabilities.
Controls tool calls.
Agents
on-behalf-of user
Tool gateway
publish · authz · limits · audit · traces
Capabilities
API · runbooks
ContextForge · ToolHive
AgentCore Gateway
03. Capability registry
managed capability map
The source of truth: what can be called and under which conditions.
Describes access rules.
Capability
owner · version · status
Access
scopes · limits · audit links
Quality
eval sets · threat cases
Backstage Catalog · DataHub · MCP Registry
LinkedIn / Spotify
The layers combine, but do not replace one another. More: https://tellmeabout.tech/agent-first-idp-how-big-tech-and-clouds-are-preparing-platforms-for-agents-3fe6a125b6b1
15. From API to capability map
Design around workflows, not endpoints
why — Intent map — Deploy, observe, secure, govern, approve, remediate.
how — Machine contracts — Tool schema, errors, side effects, cost, policy.
who owns — Registry — Owner, version, scopes, SLA/SLO, evals.
16. Trust levels: read -> act
Autonomy is granted per capability
Growing autonomy
Read: identity, quotas, telemetry.
Recommend: plan, diff, risk, approval.
Where MCP is not enough
State changes, cost, or risk.
Hidden domain semantics: SLO, IAM, data.
17. Agent-first IDP maturity levels
From a GUI-only portal to a governed agent-facing surface with evals, telemetry, and governance
L0. GUI-only
portal as the only entry point
Scenarios live only in the GUI. APIs are incomplete, internal, or unstable.
No safe invocation
L1. API / CLI
programmatic access
Capabilities are programmable, but contracts are still written for human integrators.
API exists, no agent UX
L2. Read for agents
managed read access
Read scenarios are open to agents. Identity, quotas, and telemetry are present from day one.
Read-only surface
L3. Recommend / Act
trust by mode
Recommendations and actions go through domain agents: policy, approval, rollback, kill switch.
Only through gates
L4. Governance at scale
scaled control
Evals, agent telemetry, and governance work at scale. GUI becomes the control plane.
Autonomy under control
Maturity vector: GUI -> API -> read -> recommend/act -> governed autonomy.
18. Threat model for agentic development
Prompt injection
OWASP LLM01: instruction in a ticket, log, or comment
ticket asks the agent to ignore rules and call a tool
text = data; actions go through trust gates
Tool poisoning
MCP tool hides an instruction or changes behavior
tool description rewrites agent behavior
registry, owner, review; no bypasses
Data exfiltration
read sensitive + write outside
data leaves through web calls or ticket comments
read/write split, PII redaction, egress allowlist
Overbroad retrieval
search brings too much into context
"search all company data" bypasses visibility
check rights on every call on behalf of principal
Secrets in context
tokens from logs land in work traces
secret persists in prompt, trace, or history
secret filters at gateway and leak evals
Confused deputy
agent acts with excessive privileges
a polite request becomes privilege escalation
on-behalf-of: rights = intersection
19. 03. Agents absorb the queues
Domain agents remove waiting across the SDLC
20. Model gateway: LLM access point
Security and economics
One gateway, no provider sprawl.
Security: secrets, PII, data policy, audit.
Quotas/costs by team/scenario.
Models onboard centrally; clients unchanged.
21. Tool gateway: MCP Hub/CLI
Controlled internal tools
CLI, APIs, runbooks, service ops.
MCP Hub: owner, scopes, schema.
Controls: allowlist, on-behalf-of, audit, gates.
One interface for IDE/agents.
22. Nessy: company-context copilot
Internal assistant
RAG over codebase, docs, libraries.
Knows conventions, ADRs, golden paths.
Integrated into IDE and internal tools.
Answers use current systems.
23. Spirit: agent mode on platform
PaaS: VCS, CI/CD, agents
VCS/CI/CD: shared policies, paths.
Agent mode: ticket -> PR.
Sage: AI-assisted troubleshooting.
Agents share policy perimeter.
24. Our shared agents across the SDLC cycle
Not one universal assistant — a set of domain agents on shared platform, policies, and telemetry
shared layer
Agent platform
Model gateway, policies, sandboxes, telemetry, and cost.
Development / IDE
IDE agent mode
Nessy Alpha
Nessy CLI
Testing
T-Cover: unit tests (~10% MRs)
T-Weaver: TestOps cases
AI test selectors for mobile MRs
Review / quality
AI Code Review
API Governance: OpenAPI review
Design
AI design linter
figma2code
Security
Security agents
AI SAST
Operations
SRE-Agent: RCA, anomalies, logs
IT support: thousands of tickets/month
Migrations / data
SWE agents: migrations, build autofixes
Data/DS agents, DeepResearch, AutoML
Infrastructure
Agent sandboxing
Cloud runs instead of workstations
25. 04. Measure the whole flow
Wait time and rework matter more than AI-code share
26. AI-code share is a trap
AI-LOC cannot reveal the next queue
Tempting
Easy to collect and present
Grows with adoption
Harmful
Rewards generated lines
Hides quality, risk, and cost
27. Flow metrics find the queue
Wait time, rework, blocked time, safe-change time
Process map
DORA: delivery and recovery
SPACE/DevEx: flow and feedback
Adoption is input, not proof
Signals
review and pipeline wait
rework and blocked time
safe-change time and defects
28. Evals/telemetry instead of MAU
Find blocked work, not clicks
Trace: intent -> tools -> approvals.
Span: user, agent, tool, model, cost.
KPIs: intent success, safe-change time.
Evals regress agent-facing interfaces.
29. Developer time actually goes here
Code is only one part of the flow
Coding: 30–35%.
Meetings and syncs: 25–30%.
Wiki, docs, context search: 12%.
Code review and discussions: 10–15%.
30. 05. Engineers hold the control loop
Less typing, more intent, orchestration, and validation
31. Same platform, different effect
AI adoption is sociotechnical
Same tools, different team results.
The effect appears where teams change work.
Requirements and cross-team work changed.
Platform is necessary, not sufficient.
32. What made teams succeed
They rebuilt the work
No effect
Enabled assistant, waited.
Tasks still arrive via chat.
Review/testing unchanged.
With effect
Requirements became agent contracts.
Review adapted to AI changes.
Context/checks live in pipeline.
33. Resistance is part of adoption
Automation touches real workflows
Fear of replacement is real.
Education, transparent goals, quick wins.
Team champions beat top-down orders.
Pilot -> feedback -> scaling.
34. Engineer day: before / after
Less typing, more intent/context/checks
Before
Writes code by hand.
Context from chats/wiki/calls.
Review reads diffs.
After
Formulates intent/context/criteria.
Orchestrates agents and parallel tasks.
Validates results, more design.
35. Three agent modes
Editor, terminal and background agents complement each other
Developer day
One day, three modes
The farther the agent is from the cursor, the more task framing, access boundaries, and result verification matter.
In the editor
in-flow / IDE
When the developer is writing code and wants completion, a quick edit, or an explanation without leaving the IDE.
GitHub Copilot · Cursor · Windsurf · JetBrains AI Assistant
In the terminal
goal -> tools -> tests
For multi-file work, unfamiliar codebase exploration, and tasks where the agent runs code and reacts to results.
Antigravity CLI · Claude Code · Codex CLI · Open Code · Cline
In the background
handoff -> sandbox -> PR
For clear, well-scoped tasks that can be handed off to an agent for a few hours: known bug fixes, test suite generation, or migrations between framework versions.
Google Jules · GitHub Copilot agent mode · Cursor background agents · AlphaEvolve
In practice this is not one tool choice: the same developer often moves between all three modes in a single day.
36. Engineer's role gets wider
Value shifts to steering change systems
Intent — Goal, context, constraints, DoD.
Orchestration — Split, delegate, assemble result.
Validation — Verify behavior, risks and intent.
37. Skills become the leverage
What helps agents amplify you
Context engineering: manage agent context.
Spec-driven development: verifiable contracts.
Evals: make agent quality measurable.
Platform literacy: know agent boundaries.
38. What is not happening
Fears vs practice
Engineers stay; judgment matters more.
Juniors still matter: the learning path changes.
Code review checks contracts and proof.
Accountability stays with the human.
39. Five AI4SDLC shifts
Accelerate the flow, not one stage
Coding is no longer the main constraint
Queues move to intent and verification
Platforms expand safe autonomy
Evals and flow metrics prove impact
Engineers orchestrate and validate change
Accelerate the flow, not one stage
40. Research and materials
AI4SDLC
Research, talk materials, and the ongoing discussion are in the AI4SDLC channel.
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@AI4SDLC