AI in Practice ·
Code Was Never the Bottleneck
AI is affecting far more than code generation. The bigger shift is happening across requirements, architecture, testing, deployment, and the way teams make decisions.
AI is changing software development faster than most enterprise processes can adapt.
The obvious shift is coding. Developers can now generate boilerplate, refactor code, write tests, explain unfamiliar systems, and move through routine tasks much faster.
But that is only the visible part.
The bigger change is happening across the entire software development lifecycle — from requirements and architecture through testing, deployment, documentation, and ongoing operations.
Used well, AI can compress the distance between an idea and working software.
Used poorly, it can just help teams create bad decisions faster.
The difference comes down to how AI is introduced into the lifecycle.
AI in software development is moving upstream
Most early adoption started with developers using copilots inside the IDE.
That makes sense. Coding is where the productivity gain is easiest to see.
But software projects rarely fail because someone typed code too slowly.
They fail because requirements are incomplete, assumptions go unchallenged, architecture decisions create downstream problems, testing is weak, or teams lose context as work moves between people.
That is where AI is beginning to matter more.
A modern AI-enabled SDLC can help teams:
- turn rough requirements into structured user stories and acceptance criteria
- surface inconsistencies before development starts
- analyze existing codebases before making architectural changes
- generate implementation options and trade-offs
- create test cases from requirements and code changes
- review pull requests for likely defects, security issues, and missing edge cases
- keep documentation current as the system changes
- help operations teams understand incidents and trace issues across logs, code, and infrastructure
The value is not simply faster coding.
It is better continuity across the lifecycle.
- 01 →Requirements
- 02 →Architecture
- 03 →Development
- 04 →Testing
- 05 →Deployment
- 06Operations
The biggest opportunity is context
Software development is fundamentally a context problem.
A developer may understand the code but not the business rule behind it.
A product manager may understand the customer need but not the technical constraint.
An architect may understand the target state but not every implementation decision being made inside individual teams.
AI can help connect those layers — but only if it has access to the right context.
That means the most useful AI systems are not isolated chatbots.
They are connected to the real working environment:
- requirements
- architecture decisions
- repositories
- APIs
- coding standards
- test suites
- deployment pipelines
- security controls
- incident history
- product documentation
When that context is available, AI becomes much more useful than a generic code generator.
It can reason about your system, not just software in general.
Faster development does not automatically mean better development
There is an uncomfortable side effect to AI-assisted engineering:
Teams can now produce code much faster than they can review it.
That changes the bottleneck.
In a traditional development process, creating the implementation was often the expensive part.
With AI, review, validation, architecture, and governance become more important.
If a developer can generate hundreds of lines of code in minutes, the question is no longer:
“How quickly can we build this?”
It becomes:
“How quickly can we determine whether this should exist, whether it is correct, and whether it fits the system around it?”
That requires a different engineering discipline.
What it takes to get AI-assisted development right
1. Start with the workflow, not the model
Do not begin by asking which AI tool developers should use.
Start by looking at where the development process slows down or loses quality.
Where do requirements become unclear?Where do developers repeatedly search for the same information?Where does testing fall behind?Where do reviews become bottlenecks?Where does knowledge live with one or two people?
Those are better candidates for AI than simply adding another coding assistant.
2. Give AI the right boundaries
AI should have clear operating constraints.
That includes:
- what repositories it can access
- what data it can see
- what actions it can take
- when human review is required
- what coding and security standards it must follow
- what information must never leave the environment
In enterprise development, the quality of these boundaries matters as much as the quality of the model.
3. Keep architecture human-led
AI can be extremely useful for architecture analysis.
It can map dependencies, summarize systems, compare approaches, surface technical debt, and generate possible designs.
But architecture is ultimately a set of trade-offs.
Performance against cost.Speed against maintainability.Standardization against flexibility.Build against buy.Short-term delivery against long-term complexity.
Those decisions require business context and accountability.
AI should improve the architect’s field of view, not replace architectural judgment.
4. Shift more effort into verification
As generation becomes cheaper, verification becomes more valuable.
Teams should invest more heavily in:
- automated tests
- security scanning
- code review
- architecture guardrails
- observability
- performance testing
- deployment controls
The goal is not to slow AI-assisted development down.
It is to make faster development safe.
5. Build organizational memory
One of the most valuable uses of AI may be preserving the reasoning behind software.
Why was this service created?Why was this vendor selected?Why does this API behave this way?Why was a particular design rejected?
Most organizations are poor at retaining this context.
AI can help capture and retrieve architecture decisions, implementation notes, incident learnings, and historical trade-offs.
Over time, that can reduce one of the biggest hidden costs in enterprise software: repeatedly rediscovering why the system is the way it is.
Where AI agents fit in the software lifecycle
The next phase of AI-assisted software development will go beyond prompting.
Agents can take on bounded sequences of work.
For example, an engineering agent might:
- read a ticket
- inspect the relevant services
- propose a change
- modify the code
- generate tests
- run the test suite
- flag anything it could not resolve
- prepare a pull request for human review
That is very different from asking a chatbot to write a function.
But the more autonomy an agent has, the more important the surrounding controls become.
Access, testing, observability, approvals, rollback, and auditability all matter.
The question should not be:
“Can the agent do this?”
It should be:
“What level of autonomy makes sense for this task?”
The role of the developer is changing, not disappearing
AI reduces the cost of producing code.
That increases the value of judgment.
Strong developers will spend more time:
- understanding the problem
- breaking work into the right units
- designing systems
- evaluating generated output
- handling edge cases
- making trade-offs
- reviewing architecture
- improving reliability
The job becomes less about producing every line manually and more about directing, validating, and integrating increasingly capable tools.
That is a meaningful shift.
But it is still software engineering.
The same principle applies to the SDLC as it does to AI generally
AI works best when it is attached to a real operating problem.
Not when it is added because the organization wants an AI initiative.
The companies that get the most from AI in software development will not necessarily be the ones with the most tools.
They will be the ones that understand their development process well enough to know:
- where AI can remove friction
- where human judgment matters most
- what context the system needs
- what controls have to stay in place
- how to measure whether anything actually improved
AI can make software development dramatically faster.
Getting it right still requires the same things good engineering has always required:
clear thinking, good architecture, disciplined execution, and people who understand the system they are building.
AI is new. The work around it isn’t.