AI assistance went from "help me write this line" to "help me build this system," reading codebases, proposing changes, and iterating toward outcomes, and that moved the engineer's job up the stack from craftsperson toward architect. If you build with AI in the loop, you already spend less time translating ideas into syntax and more time deciding what should exist and which tradeoffs matter.
AI generates code faster than you do, and it still needs guidelines and boundaries, so the work becomes choosing the right tools, anchoring the task to reality, and critically reviewing both the plan and the result. The sections below cover what that looks like in practice.
Where an engineer's time goes now
For decades, engineers spent most of their time on implementation: translating requirements into working code, debugging syntax errors, managing dependencies, and writing boilerplate, while system design and architectural decisions got a much smaller slice of the calendar.
That ratio is inverting. When AI handles more of the implementation surface, your time goes to defining constraints and success criteria, reviewing architectural decisions and tradeoffs, catching conceptual errors before they propagate, holding quality standards across generated code, and making product and system-level decisions. The work is no easier, and it consists of fewer syntax puzzles and more judgment calls.
What changed in the models
Over the past two years the models crossed a practical threshold that changes daily work, which is that they stay coherent across larger contexts and can iterate without losing the thread.
When I say "agents," I mean an LLM operating in a loop with tools such as a code editor, test runner, browser, terminal, linter, or deploy pipeline, and the loop works because of feedback from those tools. Frontier models can hold context across large codebases, recognize architectural patterns, debug subtle conceptual errors, and keep working toward a goal without getting tired or distracted.
The failure modes moved with them. You see fewer raw syntax mistakes and more of what a rushed junior might ship: wrong assumptions, overcomplicated abstractions, bloated APIs, inconsistencies nobody surfaced, and tradeoffs glossed over.
What stands out in practice is persistence. An agent can wrestle with a hard problem for half an hour, try several approaches, and often converge, and because that persistence used to be expensive and is getting cheaper, the bottleneck moves somewhere else.
Tools, judgment, and taste
My workflow now centers on three capabilities, choosing the right tools, holding quality through rigorous review, and applying taste inside a much larger space of possibilities, and each of them matters more than it did before.
Tool selection and architecture
AI can generate and debug code, and someone still has to choose the right tool for the job, set architectural constraints, define success criteria instead of implementation steps, and establish guardrails and patterns. The engineer becomes the systems thinker, which shows most clearly in fullstack work, where decisions run from the database to the UI.
Process and quality control
The models remain fallible: they run with wrong assumptions, don't manage their own confusion, and can be too eager to please. That makes review the foundation of the process, where you watch the agents closely, catch subtle conceptual errors, question inefficient constructions, keep code simple, clean up abstractions, and verify with tests, measurable acceptance criteria, and small diffs.
Review the plan as well as the diff, because if the plan is wrong, perfect execution only gets you to the wrong place faster. Judgment shows up in review more than in the first draft, whether you are shipping early-stage startup MVPs or institutional systems with compliance requirements.
Taste and product intuition
A three-person startup can now explore four products where one used to be the ceiling, and an enterprise team can try seven approaches in the time it once took to try one. Someone still has to decide which products are worth building, which approaches solve the problem, what users need, which designs will scale, and where the extra capacity goes.
Taste does not become a commodity when syntax does, because it sits upstream of implementation, and as building gets cheaper, choosing what to build gets more expensive.
Declarative work over imperative instructions
The strongest pattern I have seen is to stop dictating step-by-step instructions and instead give success criteria and let the system loop. In practice that means writing tests first and having the agent make them pass, putting the agent in a loop with browser automation for frontend work, writing a naive correct version and asking for an optimization that preserves correctness, and defining outcomes and constraints instead of implementation steps.
That move from imperative to declarative work changes the rhythm of the day, with less time typing code and more time defining what done means and checking that the result matches it.
More enjoyable work and skill atrophy
Programming is more enjoyable when the fill-in-the-blanks drudgery thins out, and what is left is closer to strategy, architecture, and problem-solving. You get stuck less often, experiments feel less risky, and problems outside your usual domain feel more reachable.
Skills also atrophy. Manual coding fluency can fade, because generating code and discriminating between good and bad code are different skills, and you can keep reviewing well even as writing from scratch gets harder. The field has been through this before, and nobody treats the loss of assembly-language fluency as a crisis.
Skills models don't replace
The capabilities that still matter are the ones models do not supply on their own:
- Knowing what to build.
- Understanding system tradeoffs.
- Maintaining quality under pressure.
- Seeing the elegant option among many working ones.
- Caring about craft when it would be easier not to.
AI makes each of those more valuable, because it multiplies whatever direction they set.
The flood of generated code
2026 will be messy, with a flood of AI-generated code on GitHub, AI-generated content across the open web, and plenty of productivity theater next to real gains, which makes quality control and the ability to tell good work from mediocre work more valuable.
Questions I'm still asking
A few questions stay open as the field absorbs this capability.
The gap between average and exceptional productivity might widen, with people who use AI well pulling further ahead, which would change what a "10X engineer" means.
Generalists may start to outperform specialists, since models are strong at local fill-in-the-blank work and weaker at grand strategy, and broad knowledge plus AI assistance might beat narrow depth alone.
In ten years, software engineering could feel closer to conducting an orchestra, playing a strategy game, or designing systems in a simulation, and I don't know which.
If much of the economy was bottlenecked on digital knowledge work, loosening that constraint could make a lot more possible than faster software alone.
How I'm working in 2026
Model capability is ahead of integrations, workflows, and organizational habits, and much of 2026 will go into closing that gap. I don't try to compete with AI on typing speed, and the question I ask on each project has moved from how to implement something to what the newly available capacity should build, with my part being the judgment, taste, and architectural direction that turn cheap implementation into a product people use.