AI Without Losing Judgment

Naseebullah Ahmadi  Senior Software Engineer, London

AI can speed up delivery, but engineers still own architecture, quality, and decisions. A simple workflow to ship faster without outsourcing judgment.

2 min read
#engineering

AI is now part of my daily workflow, but I learned quickly that speed is not the same as progress. Faster output means very little if the architecture gets weaker and the boundaries get blurry. The team starts merging changes nobody can properly defend, and that's the real risk.

At first, I used AI like overpowered autocomplete. I shipped faster, but I also reviewed less carefully and sometimes approved code that looked fine while violating boundaries.

The fix was simple: keep clear guardrails.

Core principle

AI can generate options. Engineers still own decisions.

  • AI drafts implementation, engineers own architecture.
  • AI suggests tests, engineers define quality.

If I cannot explain why a change exists, I do not merge it.

My workflow (short version)

  1. 1Define constraints first: behavior, non-goals, performance, security.
  2. 2Ask for options with trade-offs, not one-shot code.
  3. 3Generate in small slices I can fully review.
  4. 4Verify with the same quality bar every time.

That is it. No magic, just discipline.

Common mistakes with AI

  1. 1Premature abstraction.
  2. 2Boundary leaks between domains.
  3. 3Weak edge-case handling.
  4. 4Tests that check implementation, not behavior.

Final thought

The advantage is not typing faster. The advantage is keeping strong judgment while moving quickly.

Use AI to multiply your output, not to outsource your decisions.

End of entry · Keep exploring

What's next in the notebook?

Keep reading — more from where that came from.

Featured next
21 min read
0%

Designing Multi-Tenant APIs That Scale

A missing tenant filter is a data leak, not a crash. Row-level security fixes that structurally, but rate limits, connection pools, and error codes built for one instance break the same quiet way once the API runs as several.

17 min read
#engineering

Why Payment Retries Need Idempotency

A plain payment endpoint looks correct until you trace what a double-click, a timed-out request, or a redelivered webhook actually does to it. Each one turns one payment into two. Idempotency keys are the fix, at two layers most write-ups skip.

0%