Software development is the base of everything else on this site. AI features sit inside applications, and applications are built, deployed, monitored and maintained using ordinary engineering practice. Skipping that part is the most reliable way to produce something impressive that nobody can rely on.
What the work involves
Designing for the change that comes next. Most of the cost of software is paid after it ships, in the modifications nobody planned for. The decisions that matter are the ones that keep the next change cheap: clear boundaries, few dependencies between parts, and a structure that a new reader can follow without a guided tour.
Testing as a safety net rather than a ritual. Tests exist so that changing things is not frightening. That means covering the behaviour that matters rather than chasing a coverage percentage, and writing tests that fail for a real reason when they fail.
Making failure visible. Systems break. The difference between a small incident and a long one is usually whether the logs, metrics and error reporting were good enough to find the cause quickly.
Deleting things. The amount of code a team carries decides how hard it is to change anything. Removing what is no longer earning its place is one of the more valuable things to do in a codebase, and one of the least celebrated.
How I approach it
I prefer boring technology for anything load bearing. Novel tools are a cost paid by whoever maintains the system later, and that cost is easy to underestimate while the novelty still feels productive.
I would rather ship a small thing that works and extend it than plan a large thing and discover the requirements were wrong. Most of what a specification gets wrong only becomes visible once somebody is using the result.
I try to write code the way I would want to find it. That means naming things for what they do, keeping functions short enough to hold in your head, and leaving a comment where the reason for a decision would otherwise be lost.
Where it meets the AI work
Nearly every failure I have seen in an AI feature came from an ordinary software weakness rather than a modelling one. Missing tests, no observability, prompts outside version control, unpinned dependencies, no cost tracking.
That is why these two disciplines are listed next to each other rather than separately. The AI part is a component. The software part is what makes the component safe to depend on.
Related reading: the software habits that survive AI and why AI features fail in production.