Someone asked me recently: where do you get so much work to kick off? I did not understand the question in the moment, and it kept bothering me the next day. Engineering has to be developing the work. That does not mean making up work. There are tiers of work engineering should already own.
The Tiers of Work
If there are direct engineering asks coming from product, great, deal with those. That is tier one. Tier two is everything we have always wanted to do and never had room for. The bug backlog should be gone. Tech debt should be cleared, because now we can just get rid of it. Guardrails, better observability, performance work, vulnerabilities. With agents doing the typing, let us take care of all of it. Tier three is engineering pushing the product forward: coming up with experiments, telling product what is possible given the capabilities of the platform. Experiments are much cheaper now, so why are we waiting for product to hand us things to build? At worst, engineering could go off on its own initiative and dilute the product. I do not recommend that. If the company does not have product market fit, throughput is not the problem, and pointing more engineering output at a product that has not found its market risks diluting it further. But if engineering can come up with experiments, run them by product, and explain the thinking, that is valuable.
Initiatives, Epics, and Tasks
The normal Jira flow was initiatives, epics, and tasks. An initiative is a large scale piece of work, an entire module of the product. An epic is one feature. A task is a component of that feature. The conversation map matched it: product and the executive staff on initiatives, engineering leads and product on epics, engineering leads and engineers on tasks. Every one of those conversations moved up a level. Agents are tackling the tasks, so engineers should be working at the epic level and breaking epics into the tasks their agents run. Product should be dealing with initiatives and does not need to be as involved in the epics. Where a product manager might have reviewed tasks, now they should be reviewing the epics engineers produced from a larger initiative. The other half of it is what I want coming down from product: less detail and more intent. That is what lets product, for lack of a better phrase, wield more compute, because the compute is the engineers and their agents. If a product manager is still specifying exactly what has to be built, they do not need engineering very much. Engineering adds a technical and architectural flavor on top, and product can get pretty far without it.
What Did Not Change
Each of those levels requires the same technical and product breakdown it always did. Initiatives are exclusively business and user driven. Epics are a mix of functionality and business context. Tasks are often quite technical with some business knowledge attached. So if everyone moved up a level, engineers now need a lot more context about the business.
What Is Left After Typing
Once typing is automated, two things are left, and they are not the same. The first is creativity: what a redesigned experience could look like, what the moonshot ideas are. Creativity is the more democratic of the two, and a junior engineer who knows the product well can have the best idea in the room. The second is knowing what needs to get done. Wiring up error tracking is mostly mechanical work now. The hard part is knowing that zero errors in production is worth chasing in the first place, or that a particular piece of observability will pay for itself. That comes from exposure, which is why senior engineers tend to have more of it. The distinction changes the diagnosis. Two engineers with nothing to pick up can look identical from the outside. Telling either one to be more creative is the wrong instruction when what they are missing is knowing what good engineering includes.
Who Is Going to Make It
One thing this leaves open is what happens to implementation knowledge. If you hand a ticket straight to the agent and step in only at the explicit decision points it raises, and it raises fewer of them over time, you end up shipping work you understand less well than you would have before, and moving faster than someone who slows down to understand more. Is that irresponsible, or is it just the new normal? I do not have a clean answer. What I am confident about is the direction of the job. If all an engineer was doing was translating well defined tickets into code, that is the job that has been automated. If the engineer was taking the intent of the business and an understanding of the product and turning that into features through code, then only the typing went away and they got more valuable. The eighty percent of their time that went to typing can now go to collaborating, whiteboarding, architecting, discussing with product, and coming up with experiments, which is how you two to four x an engineer’s value. Engineers who are not involved in the business and the overall product understanding are not going to make it. The work that is left is not the coding. It is knowing what is worth building.