The Hard Part Has Moved

Software development is undergoing a strange inversion. For most of its history, the hardest part was the code. Teams spent weeks or months translating ideas into implementation.

Frontier models changed the shape of that work. A well-scoped prompt can produce thousands of lines of implementation. Agents can build features, refactor systems, write tests, inspect bugs, and move through codebases with real autonomy.

This does not make engineering judgment obsolete. Architecture, quality, taste, security, and maintainability still matter. But the bottleneck has moved. The preparation window is becoming the work.

Communication is how the idea is first expressed: what are we building, why, for whom, and what does success look like?

Collaboration is where the idea gets pressure-tested. Product, design, engineering, leadership, and customers expose assumptions, constraints, edge cases, and tradeoffs.

Coordination is how the work gets scheduled, assigned, sequenced, and completed. What gets built first? Who owns the decision? Where is the latest context? What is blocked?

A good PRD gives shape to an idea. It creates a shared starting point. But every PRD contains unknowns, and many of them only appear once the work reaches design, engineering, customer conversations, or ticket breakdown.

A Slack thread might contain the real decision. A meeting transcript might capture the reason behind it. A design file might show the latest direction. A ticket might contain part of the task, but not the full story.

By the time implementation starts, the context is usually scattered across notes, chats, files, recordings, designs, tickets, and memory. That is the gap.

A ticket often represents only a fraction of what the team knows. It may describe the task, but not the debate. It may include acceptance criteria, but not the reason they changed.

Human engineers sometimes compensate by asking around, remembering a meeting, or chasing the right person. Agents cannot reliably do that unless the system around them was built for that reality.

The question is no longer only how to make AI write better code. The better question is how to make sure the agent has the complete context required to build the right thing.

Writing code is becoming one part of a broader job: directing systems, managing agents, reviewing output, shaping context, enforcing standards, and turning vague intent into executable work.

The engineer of the near future may not be judged by whether they personally push fifty lines of code a day. They may be judged by whether they can safely push fifty features a day through agents, tools, and review systems.

That level of throughput is impossible if the real requirements live in transcripts, threads, and private notes that never reach the implementation context.

Slate includes a desktop tool built around a local-first model. At the center is a `.slate` folder that can sit inside or beside the code workspace.

That folder contains working context in readable files: tasks, conversations, notes, drawings, PRDs, meeting notes, recordings, and related artifacts.

When implementation begins, the team should be able to point an agent at the relevant Slate context: here is the work, the conversation, the notes, the decisions, the open questions, and everything needed to build.

A workspace is more than a folder. It is the unit of focus for a project, feature, client, ticket, release, or migration.

Inside a workspace, chats, tasks, meeting rooms, notes, recordings, drawings, files, decisions, and open questions belong to the thing being worked on.

Because that boundary is structured, local-first, and agent-accessible, it becomes a context package an AI agent can use to operate with more complete information.

Better requirements do not mean giant documents nobody reads. They mean living context: every conversation, decision, file, sketch, meeting, tradeoff, ticket, and open question connected to the work it affects.

Teams that solve this will move faster because they are clearer. Their agents will make fewer bad assumptions. Their engineers will spend less time hunting for context. Their product teams will see decisions reflected in execution.

Software is becoming easier to generate. The right thing is still hard to define. That is where the work is now.