Software Engineering in the Time of AI
AI is already in the toolkit, but it isn't the revolution the marketing claims. Its value is automation, not intelligence, and the difference matters more every month.
AI is already in the developer’s toolkit, but it isn’t the revolution the marketing claims. Its value is automation, not intelligence, and the future of software engineering will not be decided by hype or fear of missing out. It will be decided by how engineers integrate AI without losing the depth, judgment, and discipline the work needs.
Using a modern coding assistant feels a lot like working with a junior engineer. It takes the repetitive parts off your plate and speeds you up on the surface-area work. The thinking, the supervision, the decisions about whether the system is the right shape a year from now: those stay with you. Not because the models are too small, but because the questions are not the kind you answer by predicting the next token.
What it does well, what it doesn’t
The short list of what AI is good at right now: filling in boilerplate, drafting documentation that’s often off and you’ll rewrite, and producing quick implementation sketches where most are useless but the occasional one nudges you toward a better idea than the one you walked in with. That last category is where most of the productivity comes from, not because the suggestion is correct but because reading something wrong is often the fastest path to articulating what’s right.
Where it falls down, three categories cover most of it:
- System design. The model produces a default, not a trade-off. It does not reason about constraints, growth paths, or long-term maintainability.
- Context. Without a massive prompt it cannot hold the nuances of your business, your stack, or your team, and by the time you’ve written that prompt you’ve written the design.
- Production quality. “Production quality” out of an LLM means “syntactically valid and locally plausible,” which is a much smaller claim than it sounds. Shipping it usually needs careful review and sometimes a rewrite.
The workflow
Design the structure and the boundaries first: types, responsibilities, where each method lives, what it isn’t allowed to know. Write the intent out in plain language, sometimes as comments in the empty file. Then let the model fill in the implementation while you step away. When you come back, read every line, and accept the parts that match the design you had in your head, add more context or write a prompt to nudge the model in the right direction, or rewrite some areas yourself.
That turns the model into a productivity multiplier on the parts of the job that aren’t teaching you anything. It does nothing for the parts that are.
Where the “Product Engineer 2.0” pitch breaks
There is a growing pitch that AI collapses engineering roles into a single multidisciplinary hybrid: someone who does design, implementation, product thinking, and QA simultaneously because the model erases the cost of context-switching.
Holding deep technical context and deep product context in your head at the same time is cognitively expensive even when an assistant is drafting code for you. Doing both shallowly is not the same as doing both, and “we replaced the team with one engineer plus a coding assistant” will not work, because the work doesn’t shrink; it lands on one person. The assistant handles the mechanical parts; the design, integration, and review that used to be split across multiple people still need doing.
There’s also a false equivalence in the pitch: an assistant helping someone bridge disciplines is not the same as one person mastering all of them.
The “rule-based” analogy doesn’t transfer
The other argument worth pushing back on is that software engineering will be automated the way other rule-based professions have been. The analogy breaks at “rule-based.” Those fields are built on repeatable patterns with a narrow scope. Software is open-ended, full of judgment calls, and most expensive precisely where the rules run out.
The realistic split is that the routine 80% becomes assisted, and the remaining 20% becomes more valuable, not less. That 20% is system design and reviewing what the assistant produces, because the person still owns the output.
“Zero-touch feature development” belongs in the same category. It sounds like a pitch deck because it is one. Low-touch is real and already here: scaffolded code, generated tests, infrastructure boilerplate. The supervision is the job.
The model that holds up
Engineers aren’t interchangeable. They don’t all learn at the same speed, thrive in multidisciplinary ambiguity, or enjoy context-switching across the stack and the roadmap. The strength of a team is in the diversity of how its members think, what they focus on, and what they go deep on. Flatten that into one mold and you lose the specialists, the output gets shallower, and the team doesn’t survive the year.
Small squads work better. People stretch one step beyond their specialty, AI picks up the mechanical work that used to require a handoff, and specialists keep the deep knowledge that made them valuable in the first place. The goal is to push more engineers into that 20%, not to flatten the role into generalists.
Where the line moves
The line between mindless work to hand to the model and work that’s still teaching you something shifts as you grow. Noticing which is which is the part that matters, and it starts with self-awareness.
There’s a tension I feel every day: pride in hard-won abilities, and the fear of being left behind if I don’t adapt. Hand the model the work that isn’t teaching you anything and it’s doing its job. Hand it the work that is, and you stop growing.