/
Published on 28.01.2026
TLDR: A growth team member demonstrates how AI coding tools let them ship an interactive pricing calculator, promotional banners, and feature iterations across multiple platforms - work that would traditionally require engineering back-and-forth - in hours instead of days.
This is a case study in the changing boundaries between technical and non-technical roles. A person in a growth role needed to build an interactive pricing calculator that used the same backend logic as the production application. In the pre-AI world, this would mean creating a spec, waiting for engineering capacity, going through review cycles, and iterating over days or weeks. Instead, they shipped multiple versions in hours.
The workflow reveals a pattern that's becoming increasingly common. Start by using an AI tool to understand existing codebase logic - in this case, asking for a summary of how pricing was implemented in the backend. Then use that context to generate a first implementation. Iterate in the AI tool until you have something close. Pull it into the IDE for refinement. Deploy.
The specific example is instructive. The initial AI-generated calculator had a bug: it was converting dollars to credits assuming they weren't 1:1, when the pricing was actually straightforward dollar-equals-credit math. A few iterations in Slack fixed the logic. The result was two calculator versions - one for annual pricing, one for monthly with an interactive slider showing subscription streak savings.
But the pattern extends beyond the initial build. When the promotional bonus changed from one month to two months, the implementation across three pages was "one-shotted" from Slack. Code Reviewer caught inconsistencies before shipping. When user feedback required adding the same bonus percentages to all monthly plans, the work happened through a mix of IDE and Slack-based AI work.
For engineering leaders and architects, this raises strategic questions about team structure and tooling. The traditional gatekeeping model where non-engineers submit requests and wait for engineering capacity creates bottlenecks. These AI-assisted workflows don't eliminate the need for engineering oversight - Code Reviewer and internal review still happened before merges - but they dramatically shift who can do the initial work and iteration.
The risk, of course, is that non-engineers shipping code without sufficient understanding can create technical debt, security issues, or architectural problems. The presence of Code Reviewer in this workflow is notable - it provides a safety net that catches inconsistencies. But organizations adopting these patterns need to think carefully about guardrails: what can be shipped without engineering review, what requires review, and how do you maintain code quality when the pool of contributors expands beyond traditional developers?
The efficiency gains are real: understanding backend logic instantly, generating working implementations, iterating rapidly, shipping multiple versions. One person moving with the speed of a small engineering team. But "speed of a small engineering team" also means inheriting the risks of moving fast. The question is whether your organization's processes are ready for that.
Key takeaways:
Tradeoffs:
Link: How I Use Kilo for Slack and Code Reviewer to Scale My Growth Role
The content above is AI-generated based on newsletter sources. While I strive for accuracy, please verify critical information from original sources.