Using AI as a Software Developer Without Losing Engineering Fundamentals

Starter draft. Adjust the tone to reflect how you actually use these tools.

AI tooling has changed the pace of a lot of development work. It has not changed who is accountable for what ships, and the gap between those two facts is where the interesting questions are.

Where it genuinely helps#

Mechanical work. Boilerplate, DTOs, mapping code, repetitive transformations across many files. Work that is tedious but not difficult, where the correct answer is obvious once written.

Getting oriented. Arriving in an unfamiliar library, framework or codebase and needing a map before the details. Far faster than reading documentation front to back.

First drafts of prose. README files, API notes, handover documents, commit messages. Editing a draft is quicker than starting from nothing.

A second pass over a diff. Not a replacement for review, but a reasonable way to surface the obvious thing you stopped seeing an hour ago.

Generating test cases. Particularly around edge conditions — empty collections, boundary values, unusual encodings — that are easy to overlook when you are thinking about the happy path.

Where it does not#

Understanding the requirement. The hardest part of most tickets is working out what the business actually needs, which frequently differs from what was written down. That requires asking people questions.

Architecture. Trade-offs depend on the team, the timeline, the existing system and constraints that are nowhere in the code. A model with no visibility of those cannot weigh them.

Debugging your specific production issue. A model can suggest plausible hypotheses. Testing them against the real system, with its real data and real configuration, is the work.

Knowing when the answer is wrong. This is the one that matters. Evaluating generated code requires the knowledge that would have let you write it. Without that, you cannot tell confident from correct.

The failure mode worth naming#

The risk is not that AI writes bad code. It is accepting code you do not understand because it looks right and the tests pass.

That produces a codebase nobody can debug. When it breaks at 2am — and it will — someone has to reason about what it does. If that person never understood it, the incident is much longer.

My rule: do not merge what you could not explain in review. If I cannot describe why a generated block works, I have not finished with it.

How I actually work with it#

1. Understand the problem first. If I cannot state what I need, I am not ready to ask for it.
2. Ask for small, verifiable pieces. A function with clear inputs and outputs, not a subsystem.
3. Read every line. Same attention as a colleague's pull request.
4. Test it properly. Generated code is not exempt from the test suite.
5. Check the security-sensitive parts twice. Authentication, authorisation, input validation, SQL construction. Plausible-looking code in these areas is precisely the dangerous case.
6. Own the result. "The AI wrote it" is not a defence in a post-mortem.

Keep the fundamentals sharp#

The skills that make AI tooling useful are the same ones it can quietly erode if you let it:

• Reading code carefully
• Reasoning about data and control flow
• Knowing what your database is doing
• Understanding the security model of what you are building
• Debugging systematically

These are exactly what you need in order to evaluate generated code. The developers who get the most from these tools are the ones who could do the work without them — which is an argument for continuing to practise, not for avoiding the tools.

Force multiplier, not substitute#

Used well, AI compresses the time spent on the mechanical half of the job and leaves more for the part that is genuinely difficult: understanding the problem, choosing an approach, and making sure the result is correct.

That is a real gain. It is just not the same thing as the work being done for you.