I’ve been thinking about a different workflow for software development. The product I have in mind would bring project setup, product management, code generation, and review into one place.
The tools should converge
I’d start by combining much of GitHub with a product management tool like Linear, rather than treating them as separate systems.
The reason is simple: AI is changing where developers spend their time.
Traditionally, a team would define a feature, then move through architecture, engineering, implementation, testing, QA, and deployment. Building the feature took up a significant part of that process. Now that some of the coding can be automated, the constraint is shifting from writing code to reviewing it.
The compounding cost of imperfect code
Thinking of developers primarily as reviewers creates a new problem. AI tools can generate enormous amounts of code, and reviewers feel pressure to keep up. If they can’t, the speed gained during generation disappears during review.
As of July 2026, my impression is that newer models can produce code that is roughly 70 to 90% good. The rest isn’t necessarily broken. It often works, but it may be poorly structured, inconsistent, or subtly wrong.
Finding those problems in a large volume of generated code is difficult, and they compound. Every prompt or new feature can introduce a little more AI slop. It may not look like technical debt at first, but it grows over time and becomes harder to detect.
The goal isn’t to pretend we can eliminate this problem. It’s to make it more visible and manageable.
Project setup should produce living engineering guidance
One way to reduce these mistakes today is to use an AGENTS.md file that documents a project’s practices, conventions, and rules. The problem is that creating a useful one usually takes conversations with developers and lessons learned from past mistakes.
When I create one, I often start with a few ideas and basic rules. Months later, after catching several small AI-generated mistakes, I finally have a strong AGENTS.md. Each issue teaches me something else I should add. I already have versions for different technologies and frameworks, but they aren’t well organized, and I don’t have a tool to help me maintain them.
I’d like project setup to work more like a guided wizard. The system could ask about technical choices, preferred trade-offs, architectural philosophies, conventions, and framework-specific practices. Based on those answers, it could generate an AGENTS.md tailored to the project.
Either a technical person or someone in product management could start the setup. Some sections would remain open for a technical person to complete. The application would handle the underlying GitHub repository, file structure, and initial configuration, so no one would need to create and clone everything manually.
Requirements should travel with the code
Once the project is configured, the next step is defining requirements. I like the idea behind OpenSpec: requirements and acceptance criteria can live close to the code instead of being isolated in another SaaS product.
That connection also makes review better. If I can see that a piece of code came from a specific prompt or specification, I can review both the implementation and the original intent.
In this workflow, someone could create a ticket and write an initial requirement. AI could help clarify and polish it without changing its intent. The application would then put the requirement in the right place within the project’s spec structure, following the OpenSpec approach, so coding agents could use it directly.
Agents can work through a familiar board
The product could still provide a typical Kanban board with a backlog generated from those requirements. Someone could assign a card to an agent or move it into progress manually. The agent would implement the work while the application used GitHub underneath for repositories, issues, and execution cycles.
Teams could bring credentials for whichever AI providers they prefer. The coding itself is already the most mature part of this idea. Current tools can handle much of that workflow.
Code review needs a smaller unit than the pull request
Review is the most important part of the system. Tools like CodeRabbit already provide useful automated review, but they still sit in a separate layer. I’d rather make that capability part of the workflow itself.
When an agent says it’s finished and moves a card forward, the system should have already completed at least one automated review pass. It should then prepare the work for a human reviewer.
The pull request may no longer be the right unit for that review. When agents generate large amounts of code, reviewing an entire pull request at once can be overwhelming. We may need a smaller concept, maybe a segment, that groups the files changed for one cohesive part of a feature.
Each segment would include:
- A clear explanation of what changed and why
- The relevant specification or prompt
- The files and code that changed
- A risk assessment showing where attention would be most valuable
This would let developers review the work in smaller, understandable pieces instead of searching for a handful of problems across a huge diff.
An operating system for AI-assisted delivery
What I’m imagining is less another disconnected SaaS tool and more an operating system for software delivery. It would guide project setup, generate and maintain agent instructions, connect requirements to code, coordinate coding agents, and give humans a review experience designed for the volume of code AI can produce.
AI has accelerated implementation. The next opportunity is to redesign everything around it, especially the parts that help us preserve quality while moving at that speed.