Gains:
- Ability to distinguish where AI provides real speed in the software development lifecycle and where the decision and responsibility remains with the engineer
- Ability to apply a three-layered engineering discipline that verifies every code and design produced through compilation, testing and review.
- Get into the habit of clearing context to leverage AI without sharing confidential source code, credentials, and customer data
When you look at a computer engineer's day, the picture is similar in most teams: understanding a business request, designing, writing code, reading someone else's code, debugging (the process of finding out why a program is working incorrectly and fixing it), writing tests, preparing documentation, reviewing code, and attending meetings. In other words, the time devoted to the real "engineering judgment", that is, whether a solution is correct, safe and sustainable, is crushed under repetitive work. This is where artificial intelligence (AI for short; software that works on text and code with a large language model) comes into play. AI doesn't make the decision for you; It prepares you for the decision, produces a code skeleton, narrows down the bug and puts a worked draft in front of you. Throughout this module we will position AI not as an “automatic programmer” but as a disciplined pair programming partner whose output is compiled, tested and reviewed every time.
In this first unit, we clarify three things: At what stages of the software development lifecycle (the stages a software goes through from idea to production: analysis, design, coding, testing, deployment, maintenance) does AI add real value; which decisions should strictly remain with the engineer; and what is the verification and confidentiality discipline you must adhere to when doing this. Without this roof installed correctly, techniques on subsequent units can become dangerous; Because an error in the software reaches millions of users at the same time and can turn into a security vulnerability.
Concepts: Hallucination: AI's convincing fabrication of a method, library, API, or behavior that does not actually exist. Context: The input you give to the AI (code, error message, requirement, constraints). Verification: Checking the output in an independent way (compilation, testing, documentation). These three concepts are the backbone of the entire module.
In Which Businesses Is AI Accelerator, In Which Businesses Is It Risky?
Software jobs fall on a two-pronged spectrum in terms of outcomes. At one end are reversible, low-risk prep work; At the other end, there are difficult-to-return tasks that enter the production environment and may cause data loss, security vulnerabilities or interruptions. The value of AI varies depending on where you stand on this spectrum.
business type
AI contribution
Engineer's role
Code skeleton / boilerplate
Rapid generation of repetitive structure
Logic and edge status control
debugging
Hypothesis and possible cause list
Reproduction and root cause confirmation
writing tests
Test draft and scenario creation
Meaningful assert and scope checking
refactoring
Refactoring proposal
Maintaining behavior through testing
Documentation
First draft and structure
Correctness check against code
Architectural/security decision
List of options and pros and cons
Final decision and responsibility
The rule is simple: the risk of an AI output equals the damage it will incur if that output makes an error. Incorrectly suggesting a variable name is harmless; Improper authentication (checking that the user is really who they claim to be) makes the entire system vulnerable. So the first question to ask before using the output is: "What happens if this is wrong and who notices it and when?"
Caution: AI produces fluent and confident code. Fluency is no guarantee of accuracy. A language model can credibly produce a function name that does not actually exist, an incorrect parameter sequence, or even an unsafe pattern. In software, this does not remain on paper; It compiles, runs, and explodes in production.
Decisions That Should Be Left to the Engineer
Some decisions should never be fully automated; carries technical, legal and ethical risks:
- Approval for production: The release of a code into production and the responsibility for this.
- Security and architecture: Expensive decisions such as authentication, authorization, encryption and data model.
- License and copyright: Usability of the produced code in the commercial product and license compliance.
- Working with confidential data: Transactions with customer data, source code secrets and identity information.
Warning: Even if the AI says "this code is secure and ready for production", accepting this without security testing, code review and validation under real load is unacceptable. In safety-critical work, AI output is never a substitute for approval from a competent engineer; Any output that leads to a decision must be independently verified and approved by the authorized engineer before implementation.
Verification Discipline: Three-Layer Control
Apply three layers of control to use AI output like a senior reviewer rather than blindly. This is the basic reflex we will repeat throughout the module.
- Compilation and static checking: Does the code actually compile/run? Are there type errors, unused variables, non-existent APIs? What does the static analysis tool (the tool that examines the code without running it) say?
- Independent reproduction (testing): Run the code with small, known inputs and see if you get the expected output. Try edge cases (null, zero, negative, huge).
- Source verification: Every API, library version, and language feature that the AI uses should be verified from official documentation.
Verification prompt (makes it easier to check the output): "List ALL external libraries, methods, and language features you use in your code. For each one, indicate which version it is available in and label it 'must be verified from documentation'. Don't make up any APIs you're not sure about; if you're not sure, clearly write 'not sure'. Also list any edge cases you haven't addressed as a separate list."
Critique your own code prompt: "Look critically at the code you just wrote, like a senior engineer who hired you. Give concrete items under these three headings: (1) logic/edge case errors, (2) security risks, (3) performance or readability problems. For each item, write 'why is the problem' and 'suggested fix'. If there is no problem, say 'I couldn't find a problem'; don't try to embellish it."
Weak Prompt / Strong Prompt
WEAK:"Write me a user authentication function."(Result: unclear which language, which rule, which error behavior; generic code, often insecure or out of context.)STRONG:"Write an email validation function for Python 3.11. Input: string. Output: True if valid, False otherwise. Rules: empty string False; No RFC compliance required, basic format is sufficient. DO NOT USE external library. A 5-sample test below the function append block: valid, empty, no '@', double '@', containing spaces only."
The difference is in context. Powerful prompt; It includes the language, version, input-output contract, constraints, and test expectation. This single discipline greatly reduces the risk of hallucinations and unsafe code.
Mini Cases
Case 1 — Contrived method. A developer hears from AI that there is a method called date.addBusinessDays(5) in a date library and it is explained in a confident manner. Looking at the documentation, he sees that there is no such method, the correct way is a manual loop. The hallucination is captured before it goes into production with a 10-minute verification.
Case 2 — Edge state loss. AI produces a “calculate average” function; It works when tested with 1,000 rows of data. However, when the list is empty, it gives division by zero error. Since the engineer added the empty input test, he sees and fixes the error before it goes live. A single edge condition test prevents a production alarm at 3am.
Case 3 — Privacy risk. An expert is about to paste a file with an actual database connection string and API key into a public tool. Remembers the institution's policy; It replaces the secrets with <REDACTED>, reduces the code to a representative example, and asks for it. Thus, he gets help in 5 minutes, but his identity information does not come out.
Principle of Working with Secret Code and Identity Information
The most sensitive part of the software; source code secrets, identity information (API key, password, token) and customer/personal data. Basic principle: clean up before sharing, ask only the essence of the problem with a representative example if possible.
Anonymised prompt pattern: "There is an error in the following function. I replaced the actual business logic and hidden constants with representative values (API key, table names, field namesgeneric). Problem: I get error Y in input X. Just find the logic error in this representative code and explain the corrected version. [representative code]"
Tip: If in doubt, take this test: "Would my organization get in trouble if I wrote this publicly in a forum?" Even if the answer is unclear, clear it first. Resetting is always cheaper than chasing the leak later.
Common mistakes
- Using the output without compiling/testing. “AI wrote” is not a justification; Each piece of code is verified by running it.
- Making requests without context. If language, version, input-output and constraints are not given, the code becomes generic and often insecure.
- Sharing confidential information without thinking. The API key, password and customer data should not be released without being cleared.
- Confusing precise language with accuracy. The more confident the AI speaks, the more careful you should be; Confident tone is not evidence.
- Delegating the decision to AI. The decision to put into production, security and architecture remains with the engineer; AI only produces materials.
In summary
AI speeds up the repetitive and time-consuming parts of software work: skeleton code, test drafting, bug narrowing, documentation. However, the decision and responsibility remains with the engineer. Every output must pass three layers of control (compile/static, testing, source). Writing prompts with context and clearing hidden information are two key habits that we will repeat in each unit of this module. When you use AI with discipline, you gain speed; when you use it without discipline, you carry errors and vulnerabilities into production.
Application task
Choose a small coding task from your own work or from an imaginary project (e.g. a validation function). First write a weak prompt and get the output. Then apply the powerful prompt pattern from this unit: add language/version, input-output contract, constraints, and test expectation. Put the two printouts side by side and write the difference. Then compile the robust output and test it with at least three edge cases (null, zero/negative, unexpected format) and note what you find in which test.
checklist
- [ ] I added language, version and input-output contract to the prompt.
- [ ] I wrote "Don't make it up, tell me if you're not sure" and the scope constraint.
- [ ] I compiled/ran the code, checked for static warnings.
- [ ] I tested with at least three edge cases.
- [ ] I verified the APIs used from the official documentation.
- [ ] I cleared any secret code/credentials or used enterprise tool.
- [ ] I confirmed that the decision to put into production and security remains with the human.