Claude Code for Non Coders: How Chris Bryant Learned to Build HubSpot Tools Without a Back-End Background

Chris Bryant has spent about 11 years in the HubSpot world, most of them as a non-coder with one wall he could not get over. “I could never write great code,” he said. “I knew generally what I wanted, I could do front-end design, but I never really understood back-end.”

Then Claude Code came out. “All of a sudden, like back-end started making sense to me.” His firm, Bryant Works, now uses Claude Code to build custom HubSpot cards, coded actions and webhooks for clients. Chris still calls himself a front-end person. He learned the back-end work by building with the AI, and many of his first attempts failed.

Ashley Freter asked him to walk through his setup on Show Me Your Prompt. For anyone weighing Claude Code for non-coders, his account is useful because he describes the months when nothing worked as plainly as the change that fixed it.

How did Chris start using AI?

Chris runs Bryant Works, which describes itself on the show as “a HubSpot Diamond Partner” focused on operations work. He started with ChatGPT, mostly for conversation. His reason was personal: “I personally hate authoring documentation.” He liked “feeding in a sentence and getting back two or three that I can run with.”

Then a client changed his tools. Bryant Works started helping Anthropic with its own HubSpot setup. “So, obviously now I’m Claude everything,” he said. When Claude Code arrived, it was “the biggest unlock for me and the team.” The whole company is on a Claude team plan, using it for custom coded actions, webhooks, and critique on how to architect a build.

How does Chris organize his work in Claude?

He keeps his work in Claude projects. He described a project as a folder: “with instructions in there and a memory in there and past conversations in there and important files all in there.” He keeps one each for statement-of-work generation and documentation, one for “a very, very overly aggressive business coach,” one for his garden, and one where he logs workouts.

The statement-of-work project comes from knowing his own weak spot. “I suck at documentation. I suck at authoring contracts and statements of work. But I can carry on a conversation with somebody to derive a really solid statement of work.” So he runs scoping calls with the end in mind: “I ask questions that lead to those cuz I know I’m taking this transcript and putting it into an AI to then give me an output document.”

He also leans on skills, which he explained for listeners who had not used them. A skill is a short set of instructions, “meant to be like 40 to 50 lines of text,” that Claude “can hook into… when it deems it necessary.” A statement-of-work skill, for example, keeps every document to the same standard.

Why did Chris’s first AI coding sessions fail?

Before the skills came along, Chris would spin up a session and work through the code with Claude, and “it was just candidly Um nothing really worked. It was horrible.” He knows why. “Claude didn’t have memory, it didn’t have context, it was trying to just take my line of make this thing work and make it work.”

Chris was handing the model a single vague instruction with no plan behind it. Researchers who study AI coding have measured what goes wrong in sessions like that:

• False speed. METR ran a controlled study of 16 experienced open-source developers on 246 real tasks. With AI tools they took 19% longer to finish, and afterward still believed AI had sped them up by 20% (METR, 2025).
• Hidden flaws. Veracode tested code from more than 100 models and found 45% of samples failed security tests and introduced OWASP Top 10 vulnerabilities (Veracode, 2025).
• Fading memory. Chroma tested 18 models and found performance grows increasingly unreliable as input length grows, a pattern it named context rot (Chroma Research, 2025).

The METR group were experts working in code they knew. A non-coder has fewer instincts for catching a slow build, a leaky webhook, or a model that has lost track of the goal two hours into a chat.

What is the Superpowers skill, and why does Chris swear by it?

Ashley asked for the one prompt he cannot live without. His answer was a Claude Code skill called Superpowers. “Wasn’t authored by me, but it has drastically changed how I author things.” It is an open-source set of skills by Jesse Vincent and Prime Radiant, available on GitHub, and its README lays out a fixed order: brainstorm with questions before any code, write a plan of small tasks, run each task through a fresh subagent, follow test-driven development, then review against the plan. The README calls them “Mandatory workflows, not suggestions” (Superpowers on GitHub).

What Chris values first is the pushback. “It pushes back, it doesn’t let you jump into writing the code, it asks you things, it says, ‘What approach should I take? What have you thought about this? What other things should I do here?’ And then it iterates on those.” It writes “great plans” and “great implementation documentation,” and orchestrates sub-agents to do the work.

The second thing he values is the fresh start. “It constantly starts and stops new sessions. So you’re getting fresh context with just what you really discern from the last conversation that you had. So you run into very, very little hallucination actually.”

Chroma’s context rot findings fit what he describes. Models did worse as the input grew longer, and a fresh session keeps each input short.

He is clear about the limit. “Now granted, I’m not building like enterprise level software. I’m building tools to solve client problems like… a custom card inside of HubSpot or a, you know, a webhook.” For tools that size, the skill makes Chris work the way a careful engineer would. It asks before it builds, writes the plan down, builds in small pieces and checks each one.

Can Claude Code turn non-coders into developers?

Chris answered with a theory about careers. People used to aim to be T-shaped: general knowledge across a field and one deep specialty. “With AI, you can get more W-shaped people, where now you can go deeper in a couple different areas because AI has filled the gap.”

He is his own example. He went deep on front-end design years ago and never got anywhere with back-end code. Now the hard part of his coding day is small stuff, like pasting API keys into an environment file, because most of the work is iterating and testing with the AI.

He sees the same shift for others. Plenty of people “can get things three-quarters of the way there or two-thirds of the way there, but getting it over that last little hump is their issue.” He thinks AI can get them over it. An account executive who was never a solutions architect “can dabble a little bit” in solutioning, because they know which questions to ask.

He does not pretend the change is painless. “I personally had some clients where they’ve let go of roughly half their support staff because of things like this,” he said, and AI “very clearly has” taken some jobs in some markets. He expects the gains to go to “the people who lean in to having AI fill the gaps.”

How should a non-coder start with AI?

Chris’s advice is to lower the stakes and play. “Start with just a question that you would typically Google” and watch the follow-up questions the AI asks back. He planned his vegetable garden that way: “These are my bed sizes. This is my zone. What can I plant?” He picked from its list, added what his kids like, and got a plan with a timeline. The printed PDF is “stapled to my shed.”

His other rule is to poke around: “too many people are afraid to like click buttons in software just to see what happens… Don’t be afraid to ask weird questions… make mistakes. That’s the only way that we’ve we’ve learned.”

He also learned to choose his words carefully when he sets up a project. He told his business coach project to be aggressive, and it overdid it. “I just needed you to challenge me on some of my ideas,” he told it. By his telling, the reply amounted to “Chris, you’re a horrible individual and nothing you do will ever work.”

He had to tone the instructions down.

Chris watches the cost of all this, too. His Claude Code stats told him he had sent over a million messages, and he joked on LinkedIn that he is “single-handedly boiling the ocean.” From his home in Poland, he is now looking at running local models on his own machine, maybe on solar power.

What order does Chris build in now?

Pieced together from what he described on the show, his routine runs in this order:

1. Plain questions first. He started in chat with the kind of thing he would have searched for, and let the AI’s follow-up questions shape the answer.
2. A project per job. Instructions, memory, past conversations and files sit together, so a session starts with context instead of one bare line.
3. A skill that plans before it codes. Superpowers asks what approach to take and what he has already thought about, then writes the plan down.
4. Small tasks in fresh sessions. Each task starts clean and carries over only the decisions from the last conversation.
5. Keys and setup by hand. He pastes API keys into the environment file himself; most of the rest is iterating and testing with the AI.
6. Tests and review. Superpowers follows test-driven development and checks the finished work against the plan.

Chris’s lessons on Claude Code for non-coders

• Projects as folders. Instructions, memory, past chats and files together, one project per job.
• Scoping calls run for the transcript. He asks scoping questions knowing the transcript will become the statement of work.
• A skill that pushes back. Superpowers asks questions and writes a plan before any code.
• Fresh context per task. New sessions that carry only the decisions keep hallucination low, in his experience.
• Stated limits. He builds client tools, cards and webhooks, and says plainly that enterprise software is a different job.
• Low-stakes practice. Googleable questions, clicked buttons and weird questions are how he learned.

Where should a non-coder go from here?

Once you move past asking AI questions and start building, borrow a careful engineer’s order of work before the first line of code. Chris’s early sessions ran on free prompting and went sideways; his later ones followed that order and held up.

Chris’s vibe coding improved once a written process sat behind it, and sales teams using AI show a similar pattern. In The State of Sales Enablement 2026, 40% of teams with strong process adherence rated AI’s impact high, against 21% with weak adherence. Supered is the Behavior Layer that puts a sales process in front of reps inside HubSpot and Salesforce, in the flow of work, so people and AI work from the same plan. Our guide to AI sales enablement goes deeper.

If your team builds with AI, write the process down the way you would for any repeatable work; our guide on how to write an SOP people follow applies to AI workflows too. And if you are building custom HubSpot automation, read our map of HubSpot workflow dependencies before your first webhook goes live.