I have started contributing to our codebase again. Actual pull requests, not just feedback on specs or small copy changes.

It is not because I suddenly became a better engineer. Cursor, Claude Code, and Codex removed much of the gap between knowing what should happen and being able to implement it.

That gap is one of the hidden reasons organizations become slow.

The founder, customer-success manager, salesperson, or analyst notices a problem. They hand it to someone who can execute. That person needs to be briefed, reconstructs part of the context, converts it into a specification, and makes a set of reasonable assumptions. The work moves, but the original reasoning becomes thinner at every step.

As an engineer turned founder, I have always found the distance between “the customer said X” and “the engineer shipped X” maddening. The hard part is often not writing the code. It is preserving what the customer actually meant, why the request matters, what was tried before, and which tradeoff the team is making.

Recently, I asked our system to synthesize feature requests from that week’s customer conversations. It produced a ranked engineering brief grounded in exact customer evidence. I drilled into one item and asked it to implement the change. A coding agent started with both the codebase and the conversation that generated the request.

An agent launched from customer evidence into the product codebase

The agent knew the why, not just the spec.

This is the more important effect of AI on organizational design. It is not simply that every existing role becomes faster. People with the most context can increasingly execute without first translating their intent through several other people.

We built organizational hierarchies partly to scale execution. Layers of people turned decisions into plans, plans into specifications, and specifications into work. Each layer added expertise, but it also introduced latency and information loss.

AI does not eliminate the need for specialists. Code still needs review. Product decisions still benefit from disagreement. Security, architecture, and maintainability do not disappear because the first implementation became easier.

What changes is where collaboration starts.

Instead of spending the first cycle transferring enough context for someone else to begin, the person closest to the problem can produce a concrete artifact. Specialists can review something real, challenge assumptions, and improve the solution.

The bottleneck moves from translation to judgment.

The teams that learn to work this way will not just be leaner. They will move differently. More of the original context will survive all the way into execution, and the distance between learning and changing the system will keep shrinking.