I'm not a software engineer. My background is GTM. So now I'm a GTM Engineer I guess. I've spent years helping SaaS founders figure out how to get from founder-led execution to scalable growth. Today, though, I see GTM more as a code problem and spend a surprising amount of time shipping software.
The most interesting concept to borrow was the engineering process.
Programming and engineering are different jobs.
Everything I work on starts as a Linear issue.
Whether it's a GTM workflow, an internal tool, or a client feature, it goes through the same pipeline:
Backlog → Todo → In Progress → Review → Done
When an issue is ready, an orchestrator agent picks it up:
The interesting part isn't that there are three agents—it's that every stage leaves its reasoning behind. Each handoff becomes a comment in Linear explaining what changed, what was tested, and what still looks risky. The ticket itself becomes the audit trail.
That completely changed how I work and pushed me toward separating everything into small tasks.
I borrowed almost directly from Matt Pocock's workflow: grilling ideas before writing code. Since only 20% of my time is coding, I had to adapt it to work.
My flow looks like this:
/grill-me
/to-prd
Checklists work exceptionally well for LLMs—they force the model not to skip steps.
This has probably improved quality more than switching models ever did.
Reserve expensive thinking for Claude Code:
Everything else runs on open models:
These don't need frontier intelligence—they need throughput. Moving that work onto DeepSeek also let me remove a paid search API because agents could perform the same discovery directly.
I stopped thinking about prompting as the important part. Most quality comes from context.
Everything important about my business lives inside the repository:
CLAUDE.md
— Business rulesEvery new session starts with this context already loaded—lean and on-demand. That means I'm no longer explaining my business over and over. I'm onboarding agents the same way I'd onboard a new teammate, with core context and pointers to their systems (CRM, email, transcripts, etc.).
This is a very different workflow from what I imagined AI-assisted development would look like a year ago.
I still don't think of myself as a software engineer. But I also don't think that's the point anymore.
For me, the most interesting thing was that it gave me access to an engineering process. I'm curious whether other people without a traditional engineering background are converging on something similar.
What parts of software engineering have you borrowed? Which open models have earned your trust for high-volume work? My guess is that a lot of us are independently reinventing the same operating system.