What an AI-era engineer's day looks like
1. A typical day, 2026
Same dial, eleven years forward. Same kind of company. Same senior IC, on the same kind of product team. Web service. The codebase is bigger now and has the model wired into every part of the workflow.
Here's the day.
| Time | What they do |
|---|---|
| 9:00 | Coffee. Open laptop. Read overnight summary the model produced of Slack, email, alerts. |
| 9:30 | Stand-up. Five minutes. Most updates are shared as written summaries beforehand. |
| 9:35 | Pick up the next problem. Spend twenty minutes turning it into a clear spec. |
| 9:55 | Ask the model to draft an implementation against the spec. |
| 10:05 | Read the draft. Catch two things that miss the requirement. Catch one subtle correctness bug. |
| 10:30 | Refine the spec. Ask for a second draft. Read again. |
| 11:00 | Ask the model to draft tests against the spec. Read them. Add three edge cases the model missed. |
| 11:45 | Run the tests. One fails. Read why. Push back on the model's fix because it would mask a real bug. Direct it to the right fix. |
| 12:30 | Lunch. |
| 13:30 | Open a pull request. Half the body is the spec, half is the implementation notes the model drafted. |
| 14:00 | Two reviewers ping. One catches a thing about the database index that neither the engineer nor the model noticed. Fix. |
| 14:45 | Reviewer approves. Merge. CI runs. Deploys to staging. |
| 15:00 | Watch staging metrics. Compare them to the model's predicted impact. Numbers match. Promote. |
| 15:30 | Review three other engineers' pull requests. Two were drafted with the model. Catch one place where the model produced confident but wrong code about retry semantics. |
| 17:00 | Plan tomorrow's problem. Write the rough spec while it's fresh. |
| 17:30 | Close laptop. |
The shape is recognizable. The time inside each block is different.
2. What shifted
Where did the hours move? A side-by-side helps.
| Activity | 2015 share of day | 2026 share of day |
|---|---|---|
| Typing code from scratch | High | Low |
| Reading code (yours or the model's) | Medium | High |
| Writing specs in plain English | Low | High |
| Verifying behavior | Low | High |
| Reviewing other engineers' code | Low | Medium |
| Looking up syntax and docs | Medium | Low |
| Waiting for builds, deploys, tests | Medium | Low |
| Debugging | Medium | Medium |
Typing went down. Verification went up. Specifying went from a quiet skill to a core skill. Reviewing other people's code became more of the day, because the volume of code each engineer produces went up.
3. The skills the day rewards now
Three skills get used hardest.
Specification clarity. The engineer's twenty minutes from 9:35 to 9:55 set the quality of everything that follows. A vague spec produces a wrong draft, which produces wrong tests, which produces a buggy ship. A clear spec produces a draft the engineer can read in ten minutes and approve.
Reading code fast and well. The engineer reads the model's draft, the model's tests, three colleagues' pull requests, and the staging dashboard. Reading is the most-used skill of the day. Reading well means catching the subtle thing in the middle of a confident-looking draft.
Judgment about what's wrong. The model produces confident, plausible code. Some of it is correct. Some of it has a subtle bug. Some of it is wrong about the system it's writing for. The engineer's job is to catch the wrong ones before they ship. This is the skill that has gone up the most in value.
4. The honest summary
Typing minutes drop. Judgment minutes rise.
The next unit puts the full skill stack side by side.