Engineering is eating the org chart.
Most software companies were built around a process that looked something like this:
Product wrote the requirement
Design made the mockup
Engineering shipped it
Data measured the result
Support brought back what customers said
This worked for a long time. Each team had its own tools, words, and list of things to do. At every step, someone new had to learn what was going on. Some details got lost along the way.
Say customers are getting stuck while they set up an account. An engineer can read the support messages and look at session traces. They can check the product data and find the bad state change. Then they can fix the flow, test it in a browser, and release it to a small group. The same person can watch the result.
AI agents let one engineer stay with the problem for much longer. The engineer can start with a support message and find the accounts that had the problem. They can reproduce it, change the product, test the change in a browser, and plan the release. They can also watch what happens after the release.
The problem stays with one owner. So does the context around it. There are fewer handoffs and fewer chances to lose an important detail.
Enter engineer mode.
The name is a nod to Founder Mode, Paul Graham's phrase for the way Brian Chesky ran Airbnb. Chesky stayed close to the work because every layer could hide something important. Engineer mode follows the same instinct.
AI agents help one engineer work across different tools and systems. The engineer keeps the full story in mind and owns the final call.
One task can now cover much more ground. An agent can open files, use company tools, make changes, run tests, and show what it found. That work can continue for hours while the engineer works on something else. One engineer can also run several agents at the same time.
This puts more weight on the engineer's judgment. A senior engineer has to pick the right problem, split up the work, check the results, and own what ships. The agent needs a clear goal, the right context, firm limits, and a way to know when the work is done. Clear direction leads to useful work. Careful review keeps bad work out of the product.
That person knows why each step happened. They can connect what a customer said to a code change and then to a product event. The reason for the decision stays close to the work. The next person does not have to piece the whole story together again.
Other people can work this way too. Product managers, designers, operators, and analysts can turn what they know into small tools. They can use agents to test an idea before asking for a full engineering project. The work can start with the person who understands the problem best.
There is a catch. More reach brings more responsibility. The engineer must know when to bring in a designer, researcher, data specialist, or another expert. A vague request can send several agents toward the wrong problem, and every result still needs human review.
The checks should match the risk. Tests check the code, browser tests check the interface, and product events show what happens after a release. Give each agent only the data, tools, permissions, and budget it needs. Keep a record of important work, and make one person responsible for the final call.
The challenge now is finding the right balance. What should an agent be allowed to see? What should it be allowed to change? We need to keep figuring this out as AI systems develop.