AI is already in the development workflow. The useful question for founders and CTOs is whether it is increasing real delivery capacity, or simply producing more code that still has to be understood, reviewed and maintained later.

At Blocshop, we have spent the last two years refining a practical AI development process in which senior developers typically work at around $300 per month in token consumption per developer while reaching roughly 1.5x to 3x productivity gains.

That result comes from using AI inside a disciplined engineering process, where the developer still understands the code being changed, the trade-offs involved and the maintenance consequences of accepting the output.

The problem with badly managed AI adoption is that it can look productive before the cost becomes visible. Developers generate more code, ask broader questions, paste larger parts of the codebase into prompts and accept plausible answers too quickly. The board may show more completed tickets, but the review burden grows, architecture becomes less consistent and the team starts carrying code that nobody fully owns.

Token spend is a process signal

High token consumption is often treated as a vendor-cost problem. In practice, it is frequently a development-process problem.

A developer who understands the relevant part of the system can ask AI for a bounded task, like drafting tests for known behaviour, comparing two implementation approaches, explaining a narrow function, generating repetitive mapping logic or suggesting edge cases. These requests are cheaper, easier to review and more useful because the developer has already framed the work.

The expensive pattern starts with a vague request. The model receives too much context, returns too much output, and the developer spends the next several prompts correcting assumptions that should have been narrowed before the first prompt. The team then pays in tokens, review time and attention.

Good AI usage starts before the prompt. The developer defines the task, selects the relevant context and decides which part of the work AI should support. The model helps with execution, but it does not replace the developer’s understanding of the system.

The developer still owns the change

AI-assisted development is useful only when the developer remains the owner of the engineering decision.

That means they can explain why the change was made, how it fits the architecture, what assumptions it relies on, where it may fail and how it should be tested. If that explanation is missing, the team has not gained sustainable capacity, only moved the cost into review, debugging or future maintenance.

This matters most in mature codebases, where the real cost of a poor change often appears later. A generated implementation may pass a quick review, but if it weakens a boundary, ignores an edge case or introduces a pattern that does not fit the system, the team will pay for it during the next change in the same area.

Blocshop’s process treats AI output as draft material until a senior developer has shaped, reviewed and accepted it as their own work.

Smaller AI tasks work better

The most useful AI tasks are usually narrower than teams first expect.

Asking AI to “implement the feature” gives the model too much room to infer architecture, product rules, data flow, coding standards and acceptance criteria from incomplete context. The result may look impressive, but the review burden returns to the developer.

Better results come from smaller requests, such as: draft tests once the expected behaviour is clear, compare implementation options before coding starts, summarize a narrow module before changing it, generate repetitive adapter code after the interface is agreed, or list edge cases for a defined function.

This is less spectacular than letting an agent run across a ticket. It is also cheaper, safer and easier to maintain.

How Blocshop applies this process

Blocshop helps development teams use AI without turning it into uncontrolled spend or shallow code ownership.

The work starts with the team’s current delivery process, incl. how tasks are prepared, how context is selected, how developers use AI during implementation, how code is reviewed and where senior judgement has to stay in control.

For teams already using AI, improvement usually means smaller task boundaries, less unnecessary context, clearer review expectations and better use of AI for tests, repetitive implementation and focused analysis. For teams earlier in adoption, it means building the right habits before poor usage becomes normal.

AI can make senior developers significantly faster, but the gain only matters if they still understand what they are building. Blocshop’s experience shows that roughly 1.5x to 3x productivity gains are achievable with around $300/month in token consumption per senior developer, provided AI is used as part of a disciplined engineering process rather than as a substitute for one.

Feel free to schedule a short consultation to see if your team's token consumption can be optimized too.