Enterprise AI, explained through practice
AI Across the SDLC:
From First Requirement
to Working Software.
Follow a software engineer from a business requirement to a running service. See where AI helps, what the engineer must decide and how each stage connects to the next.
Work as an enterprise.
Make useful changes in small steps. Keep feedback fast, ownership clear and the evidence easy to inspect.
An engineer is asked to add a feature to an existing application. Before writing code, they need to understand the requirement, find the relevant parts of the system and get the project running. After the change, they need evidence that it works, a review and a safe route into service.
These connected activities make up the Software Development Lifecycle (SDLC). AI can help throughout the journey. Its value depends on the context it receives, the actions it is allowed to take and the checks applied to its output.
We follow the engineer from the initial requirement to a running service. The customer's need gives the work its purpose.
One engineer. One change.
The whole delivery journey.
Select a stage to see the task, the AI contribution and what the engineer carries forward.
Less rework.Feedback connects
the whole journey.
Follow the cycle
Understand the requirement, explore the code, make a bounded change and check the result. Keep the evidence and feed what you learn back into the next activity.
The engineer works with a product owner to agree the outcome, with reviewers to challenge the change and with the people responsible for operating the service. These are shared responsibilities, even though we follow one engineer to make the journey easy to understand.
The circular view shows feedback, not a rigid sequence of gates. A test failure can send the engineer back to the design. A release check can reveal a configuration problem. Customer feedback can change the next requirement.
Understand the change
before opening the editor.
The engineer and product owner turn the request into behaviour they can explain, implement and check.
“Let customers check their order status.”
This describes an intention. The engineer still needs to establish which records customers can see, where the status comes from and how the page behaves when data is unavailable.
The first conversation is about the service. Which statuses already exist? Who updates them? How current is the information? Can an order be cancelled? What should someone see when they have no orders?
AI can turn meeting notes into a draft brief, identify ambiguous wording and suggest missing cases. The product owner confirms the intended behaviour. The engineer checks the system's actual capabilities. An invented delivery date or status would make the brief misleading.
For this walkthrough, the agreed scope is a read-only page for signed-in customers. It shows their own orders, the recorded status and its update time. If the data cannot be loaded, it explains that rather than inventing an update. The existing status source remains authoritative.
Make the existing project
work before changing it.
The engineer starts with shared source code and establishes a reproducible local baseline. Production remains separate.
GitHub repository
Code, history and pull requests
Engineer's laptop
Editor, runtime and local tests
Checks and test data
Existing behaviour before the change
Development application
Runs with safe test configuration
Keep the hand-offs explicit
A local change needs shared review, configured checks and a separate release process before people use it in the running service.
In this example, GitHub holds the shared repository. Cloning brings its source and Git history into the engineer's workspace. The README then explains the required runtime, dependencies, configuration and commands. These are separate setup steps.
The engineer uses approved access, development configuration and synthetic customer records. They run the existing checks, start the application and inspect the current account area. If the baseline fails, they investigate or record the failure before attributing it to their change.
AI's contribution: explain unfamiliar setup instructions, map the folder structure and help interpret an error using relevant, sanitised output. The engineer verifies suggested commands before executing them. Missing permissions or secrets need the approved access process.
What the first local session looks like
git clone <repository-url>
cd <repository-folder>
# Follow the README to install and configure the project.
# Run the existing checks and start the development app.
git switch -c feature/order-statusReplace the placeholders with the real repository details. Runtime, dependency and start commands depend on that project. A managed development workspace can serve the same purpose as a laptop; this walkthrough uses a laptop for clarity.
Give AI the context.
Keep the design decision visible.
The engineer traces the existing application, agrees a small design and then asks for a focused change.
Show order status
Request the customer's orders. Display recorded status, update time and clear empty or error states.
Check access
Verify the session and enforce which orders this customer can read. Return only the fields the page needs.
Read the current record
Use the established status source. This feature does not change fulfilment or predict delivery dates.
The authorised response returns to the page. Hiding a button in the browser does not protect the underlying order data.
CONTEXT THE ENGINEER PROVIDES
Map the existing order flow
Find the account page, session handling, order access rules and existing tests. Explain how they connect; identify anything you cannot confirm.
Relevant files · Clear requirement · Limited scope
AI CONTRIBUTION / ENGINEER DECISION
A map to verify
Check the cited files and call path. Confirm that access is enforced on the server, including direct API requests.
Account page → authenticated API
Server checks access to each order
Approved fields → status displayAn explanation is a starting point for inspection.
For this scenario, assume the existing system already records status and update time and has an established customer identity model. The engineer must verify those assumptions in a real project. If the data or access rules are missing, the requirement needs further design before implementation.
The proposed feature reuses that identity model and status source. The server must enforce access to each order. The engineer also checks what the API exposes, how the interface handles failure and whether caching could mix customer responses. OWASP explains the risk of missing object-level authorisation.
AI receives the relevant files, project guidance, agreed behaviour and checks to run. It can propose the API and page changes, draft tests and explain the diff. The engineer inspects every changed file and challenges assumptions about permissions, error handling and dependencies.
A practical brief for an AI coding assistant
Inspect the existing account, identity and order-access code. First explain the relevant call path and any missing context. Propose a read-only order-status page using the existing status source. Enforce access on the server and return only the necessary fields. Include empty and error states. Keep checkout and fulfilment unchanged. Add checks for access to another customer's order. Report the changed files, commands run, results and remaining gaps. Do not deploy or change credentials.
Use this as a pattern, adapting it to the actual repository. It is an example brief, not a transcript or evidence of an executed agent run.
Test the promise.
Challenge the assumptions.
The engineer checks the agreed behaviour, including cases that a convincing demonstration might hide.
The customer can see their own order.
Use a synthetic customer and known order. Compare the page and API response with the recorded status and update time.
A successful screen is only part of the evidence. The engineer tests access directly through the API as well as through the browser. A customer who changes an order identifier must not gain another customer's information.
Different checks answer different questions. A unit test can check status formatting. An integration test can check the API's identity and order-access behaviour against controlled data. A browser test can exercise sign-in, navigation, displayed status and error states. Existing regression checks help establish that the change has not broken other supported behaviour.
AI's contribution: suggest overlooked cases, draft tests and help interpret failures. The engineer reviews the assertions against the requirement. If AI writes both the implementation and tests, both can share the same mistake.
When a check fails, inspect the failure before changing the test. The defect might be in the implementation, the fixture or the test itself. Keep the result tied to the revision tested, and state any behaviour that remains unverified.
Understand the agent’s
working loop.
This is a closer look at the build-and-check work, not another delivery phase. The engineer can delegate a limited task to an agent.
Decide.Record the work.
Respect the limits.
Follow the cycle
Understand the requirement, explore the code, make a bounded change and check the result. Keep the evidence and feed what you learn back into the next activity.
A coding assistant may suggest changes. In an agentic workflow, it can also use tools to inspect files, edit code and execute checks within its permitted environment. That workspace could be local or hosted. It should not be confused with the production application.
The surrounding agent harness supplies tools and context, applies permissions and stopping rules, and records actions. For our order-status change, the permitted task might cover the page, API and tests in a branch, using synthetic data and no production credentials.
The agent inspects, proposes, edits and runs checks. If a check fails, it can investigate and retry within an agreed limit. Missing access, an unclear requirement, unexpected changes or exhausted limits should result in a handover with the diff and execution results.
Project instructions help the agent work consistently, but access controls must enforce the boundary. Repository content and tool output should not be allowed to expand its permissions. See GitHub's guidance on agent limitations and responsible use for a concrete product example; capabilities vary by tool and configuration.
Move the change beyond
the engineer’s laptop.
The engineer shares a proposed change, responds to review and follows the team’s release process. Each step has a different purpose.
Keep the hand-offs explicit
A local change needs shared review, configured checks and a separate release process before people use it in the running service.
A commit records a local version. A push shares that version in the remote repository. A pull request proposes merging the branch and gives reviewers a place to inspect the diff, discuss the design and examine check results.
For this feature, the PR should explain which customer need it addresses, how order access is enforced, which cases were checked and what is still uncertain. AI can draft this summary from the actual diff and recorded results. The engineer corrects unsupported claims before sharing it.
Continuous integration (CI) runs the project's configured checks on a runner. The workflow determines which events trigger it and which revision it tests. Reviewers inspect the results and resolve concerns before merging under the repository's policy. CI is automation, not necessarily AI.
The release process then builds an identifiable application version and validates it in staging, a separate test environment. Where practical, promote the same build through environments with the appropriate configuration. Recheck the version that will be released, particularly if merging changed what was tested.
Before production, establish who owns the rollout, what signals would stop it and how recovery works. A gradual rollout or feature flag may help when supported. Turning a page off does not by itself secure an exposed API; the access rules must remain effective.
Where continuous delivery and continuous deployment fit
Continuous delivery keeps changes ready to release, with a release decision when needed. Continuous deployment automatically releases changes that meet the configured conditions. The choice depends on the service and its risk. Neither term means skipping verification.
AI's contribution: explain build failures, prepare release notes and help interpret staged test results. Release permissions, approved configuration and the decision to proceed remain controlled by the delivery system and accountable owners.
Find out whether
the change helped.
Customers now use the released page. The engineer and service owner observe its behaviour and decide what to improve next.
For the order-status feature, watch API errors and response time, check that status information is sufficiently current and look for failed customer journeys. Handle logs and telemetry with appropriate privacy controls. An alert needs an owner who can investigate and act.
The business question is whether customers can obtain an accurate update with less effort. Compare status-related enquiries against an agreed baseline, allowing for changes in order volume and other releases. A reduction is an outcome to investigate, not a result we can assume from shipping the page.
AI's contribution: summarise approved operational signals, suggest investigation paths and help draft a well-evidenced follow-up issue. The engineer checks those interpretations against the underlying data. Feedback returns to the next requirement.
Clear ownership supports delivery
Product teams own service outcomes. Shared platforms provide usable foundations. Assurance defines proportionate controls and evidence.
To use this approach across an organisation, product teams need clear ownership, shared platforms need to make setup and release usable, and assurance needs to define proportionate controls. A good delivery path lets engineers find the right guidance without inventing the process for every change.
I would start with one team and a type of change they understand. Measure time to a useful release, review effort, rework, defects and recovery alongside AI and supervision costs. Expand when the whole delivery outcome improves. More generated code or pull requests alone does not show that improvement.
AI assists delivery in this walkthrough.
The order-status feature itself does not need an AI model. If you build AI into a product, its lifecycle also needs model-behaviour evaluations, appropriate data controls, and checks for quality, cost and latency.
The journey connects a clear requirement to a working service. AI can help at every stage, but each handover still needs something the next person can inspect: an agreed brief, a reviewed change, test results or a release record. That is how a faster coding step becomes part of reliable delivery.
Practise checking a patch.
This lab teaches one technique from the delivery journey: checking whether a proposed change meets its requirement. It uses a separate service-request form that must reject blank descriptions. It does not implement the order-status feature above. The download includes a Python application, SQLite storage, 18 tests and review notes.
Explore the validation exercise and its recorded results
" "if not summaryThe incomplete candidate rejects "", but a string containing spaces is not empty. The corrected function trims surrounding whitespace first, then rejects an empty result. That order matters.
AI can draft tests, but the patch and its tests can share the same misunderstanding. Derive acceptance cases from the requirement, inspect the assertions and include boundaries that challenge the implementation.
LOCAL PYTHON EXERCISE / SAME SEVEN TESTS
Blank input is accepted.
Spaces and tabs slip through.
The specified unit checks pass.
The incomplete candidate is deliberately constructed for this exercise. These are local unit-test results, not a recorded autonomous-agent run or a production benchmark.
EXTENDING THE EVIDENCE / LOCAL APPLICATION
Follow the request all the way to storage.
The demonstration connects a browser form, a Python HTTP handler, the validation function and SQLite. The article simulation above is separate from this application.
| Request | HTTP response | Storage result |
|---|---|---|
| Empty or whitespace-only text | 400 · Invalid request | No row saved |
| Missing or non-text description | 400 · Invalid request | No row saved |
| Non-blank text with surrounding spaces | 201 · Created | Trimmed text saved once |
| Wrong content type | 415 · Unsupported media type | No row saved |
Inspect a test that crosses the API and storage boundary
status, _ = self.call(b'{"summary":""}')
self.assertEqual(status, 400)
self.assertEqual(self.rows(), [])The test starts the actual HTTP server on a local port, sends the request and queries a temporary SQLite database. It tests the connection between the API, validator and storage rather than calling the validator alone.
These results establish the tested local behaviours. They do not establish production readiness, a complete browser journey, a live CI run or an independently reviewed release.
Inspect the completed Python function
def validate_summary(summary: str) -> str:
if not isinstance(summary, str):
raise TypeError("Summary must be text.")
cleaned = summary.strip()
if not cleaned:
raise ValueError("Please describe your request.")
return cleanedThe seven checks cover empty text, spaces, tabs and newlines, valid text, surrounding whitespace, preserved internal spacing and non-text input.
Unit tests verify this function in isolation. The downloadable application also has HTTP integration tests: they send requests to a real local server and inspect its SQLite database. They verify that rejected descriptions are not saved and that a non-blank description is trimmed and saved once in the tested request. A browser end-to-end test is a further layer: it should exercise submission, the visible error message and successful confirmation. Security, accessibility and operational checks depend on the application and the risk of the change.
The organisational implication: passing checks support a decision within their scope. Seven passing unit tests do not establish that a complete service is ready for production.
Python 3.10+ · Standard library only · No AI API key required
Run it on your laptop
Extract the application ZIP and open a terminal in its folder. Run the tests first, then start the local server.
python -m unittest discover -s tests -v
python app.pyOpen http://127.0.0.1:8000 in your browser. Submit empty text, spaces and a non-blank description. The server rejects blank input and stores valid text in a local SQLite file. Use fictional requests. Press Ctrl+C in the terminal to stop the server.
Use python3 or py if that is your installed command. The README explains the file structure and limitations.
What is ready for a repository, and what is still to verify?
The package includes a workflow that can run the tests on a GitHub push or pull request, plus a proposed PR description and a browser-check checklist. They are prepared source files. No public PR, remote workflow run, independent review or production release is claimed.
Before wider use, verify the browser journey and add the authentication, operational and security controls appropriate to the service. The local teaching server is not a production deployment.
SOURCES AND SCOPE
Check the mechanics.
The order-status journey is an illustrative design and delivery walkthrough. Its test cases are proposed, not executed results. The separate optional lab records seven validator unit tests and eleven local HTTP integration tests on Python 3.12.14. It does not establish a browser end-to-end journey, a remote CI run, production readiness or an AI productivity improvement.
- GitHub: cloning a repository
- GitHub: pull requests
- GitHub: continuous integration
- GitHub: deployment environments
- GitHub: responsible use of agents
- OWASP: object-level authorisation
- Python: unittest
No client systems, confidential material or client delivery outcomes are reproduced. Tools and available controls depend on the selected configuration.