AI-assisted software development in practice
Where AI genuinely saves time in a development workflow, where it hits real limits, and why technical understanding becomes more important, not less.
AI tools have been part of my day-to-day development for a couple of years. The gap between „AI as fancy autocomplete“ and „AI as part of a real workflow“ is wider than most LinkedIn posts suggest. An honest snapshot from practice – no salvation promises, no reflexive dismissal.
AI as code generator vs. AI as workflow component
GitHub Copilot is essentially better autocomplete: it completes lines, suggests function bodies, guesses the next three lines. Useful, and it saves measurable typing effort in verbose languages. What it doesn't change is how a team builds software – the thinking stays the same, only the fingers get relief.
Tools like Claude Code and Codex operate differently. They get a repository, a task, some constraints – and produce multi-file changes, test runs, sometimes iterative self-correction. The shift is qualitative, not quantitative: you stop discussing syntax and start discussing outcomes.
I use both in parallel. Copilot stays in the editor as an accelerator for boilerplate every developer has memorised. Claude Code or Codex get the tasks that are clearly scoped and touch multiple files – for example, „add pagination to this API and propagate the new signature consistently into the frontend, including tests“.
Where AI genuinely saves time today
Boilerplate benefits most reliably: forms, CRUD endpoints, DTO mapping, test scaffolding, data migrations. Anything an experienced developer would write in 20 minutes and rather review in five. The savings grow with codebase consistency – clean repositories with clear conventions get better AI output than historically grown monoliths.
Refactoring is the second strong case. Field renames, extracting an interface, mechanical call-site updates – tasks that used to be pure grind become accessible. Refactorings you parked for cost reasons deserve a sober re-evaluation.
Tests and documentation gain time too. AI produces plausible unit-test skeletons, Storybook cases, README sections or ADR drafts. It doesn't replace thinking, but it lowers the activation energy: „I'll write docs later“ becomes „I have a draft I can tidy up in ten minutes“.
First debugging hypotheses are underrated. For an error message or a stack trace an assistant produces two or three plausible explanations. Often one is right – and even when it isn't, you have a structure to reason from.
Where AI reliably hits limits
Once architecture is on the table, the air gets thin. „Should we build feature X as its own service or extend the monolith?“ is not a question a model can answer from a repository. Those decisions carry domain knowledge, team dynamics, historical trade-offs and operational reality – context no prompt fully captures.
Blind spot two: implicit knowledge in code. Older systems carry undocumented assumptions – „this column can't be null because seven years ago the import broke“. An assistant reads code, not the story behind it. Suggested changes look clean and cause chaos in production.
Security is regularly underestimated. An assistant can produce code that runs but opens SSRF, ignores rate limits or checks authentication in the wrong place. Until models carry real threat-model context, responsibility for security decisions stays with the team.
And long-term maintainability. AI-generated suggestions optimise for „solve now“, not „still make sense in three years with two team members replaced“. Without review, you accumulate a codebase that works on the surface but is internally fragmented and stylistically inconsistent.
Practice learnings
Twelve months of intensive use leave three lessons. Output quality is a function of specification quality; vague prompts get shallow results. „Spec-driven development“ isn't a buzzword, it is the obvious consequence of what these tools reward.
Code review is non-negotiable. Not as a formality but as a conscious filter. Teams that merge AI suggestions without scrutiny accumulate tech debt faster than any later refactoring sprint can pay off. I treat AI commits like pull requests from a very productive, but new, team member.
The developer role shifts – not towards „redundant“, but towards „curating“. People who specify precisely, evaluate results in context, set architectural guardrails and spot obvious weaknesses become noticeably more productive. People who just click accept produce bad code quickly.
Takeaway
AI doesn't remove the need for someone to understand what is being built. It just shifts who does which share of the production. The „soon you won't need developers“ story overlooks that the skills you used to take for granted – clear specification, critical review, deliberate architecture, honest trade-offs – become more important, not less. Do those well and AI makes you noticeably faster. Just type lines and you become replaceable – not by the AI itself, but by whoever wields it deliberately.