Casey Brown

Clay doubling down on increasing action costs while a lot of gtm-e world is laser focused on BYOK workflows with Claude Code is an interesting tension. In the last ~week Cargo shipped a CLI, Apollo.io released an MCP connector for Claude & most of my feed is Claude Code. The ecosystem energy feels entirely focused on terminal-first. I’ve loved Clay for orchestration but have increasingly felt that the UI/UX is slowing me down as I ramp up my terminal-first workflows. That said, terminal-first isn’t multiplayer yet and isn’t in it's final form - esp for larger companies where multiple humans benefit from a shared UI. What’s interesting is this is coming from the people who coined “GTM Engineer” in the first place. The early adopters Clay built the category for are the ones feeling the pull away from the orchestration layer Clay monetizes. The dispersion is probably temporary. But if Clay’s pricing move take them further from the early adopters who built the category, that’s a deliberate bet to cross the chasm to enterprise, while some subset of builders build elsewhere. Interesting to watch.

17

3 Comments

An excellent takeaway from Nate B. Jones Substack post today, particularly w.r.t. intent engineering.   Jones identifies three evolutionary disciplines in AI deployment, each operating at a different level of organizational complexity: Prompt engineering was the first discipline—individual, synchronous, and session-based. You sit at a chat window, craft an instruction, iterate on output. The value and skill are personal. Jones dismisses it as a "warmup act" useful for individual productivity but unable to scale organizationally. Context engineering is where most of the industry is currently focused. Anthropic defined it as shifting from crafting isolated instructions to crafting the entire information state an AI system operates within. The practical work involves building RAG pipelines, wiring up MCP servers, structuring organizational knowledge so agents can access it. Jones considers this necessary but insufficient—organizations can give agents access to vast data without those agents knowing what to do with it strategically. Intent engineering is Jones's proposed third discipline, and almost nobody is building for it yet. Where context engineering tells agents what to know, intent engineering tells agents what to want—encoding organizational purpose as structured, actionable parameters shaping autonomous decision-making. Jones anchors this in the Klarna story. In early 2024, the fintech company deployed an AI customer service agent that handled 2.3 million conversations monthly, cut resolution times from 11 minutes to 2, and reportedly saved $60 million. By mid-2025, CEO Sebastian Siemiatkowski admitted the cost focus had produced lower quality. Customers complained of generic, robotic responses. Klarna began frantically rehiring eliminated human agents. Jones's reading: the agent was extraordinarily good at resolving tickets fast—that was the problem. Klarna's actual intent wasn't "resolve tickets fast" but "build lasting customer relationships that drive lifetime value." A veteran human agent knows when to bend policy, when to spend extra time because a customer's tone signals churn risk. She absorbed real company values through years of context. The AI had a prompt and data access but no encoded understanding of what the organization actually needed it to optimize for. The progression matters: prompt engineering solved "how do I talk to AI," context engineering addresses "what does AI need to know," and intent engineering tackles what actually determines organizational value—"what does the organization need AI to want."

6

2 Comments

Most engineers obsess over writing better code. Very few obsess over building a better system around how code gets written. Last year, we started experimenting with a different approach inside our team. Instead of treating the AI as a code assistant, we treated it as an engineering environment we actively shape. And the shift has been dramatic. Here’s the thing. The real unlock wasn’t smarter prompts or a new model. It was building a workflow where: • big tasks don’t start with code, they start with thinking • complex work gets broken into focused agents instead of one overloaded session • every correction becomes a permanent improvement in how the system behaves • nothing ships until someone proves it works, not just says it does • elegance isn’t an afterthought, it’s a habit • bug fixing becomes autonomous, not managerial What this really means is you aren’t just coding faster. You’re engineering in a way where errors stop compounding and improvements start compounding. We’ve been running this playbook at BoloSign and the difference shows up everywhere. Cleaner diffs. Fewer regressions. Faster shipping cycles. A team that trusts the process instead of fighting the tools. If you’re building with AI every day, don’t just upgrade the model. Upgrade the operating system around it. That’s where the real 10x lives.

9

1 Comment

At face value the throughput acceleration AI enables feels like progress, faster pipelines and more commits shipped. When you look more closely however, the data reported in the 2025 DORA Report points to a harsher truth... we are moving faster with less control. The metrics behind instability, change fail rate, rework and recovery time are all trending upwards. More often than not, AI is simply automating in failure. The 2025 DORA Report surfaces four painful realities of embedding AI into your SDLC: - AI boosts throughput at the cost of higher deployment failure and rework. We are codifying instability into our pipelines. - Burnout remains flat. Productivity gains are absorbed by higher business expectations, not returned to developers. Faster delivery means faster deadlines. - Over 80% feel more productive with AI. Yet the research shows developers who slowed down by 19% still believed they were 20% faster. Perception of acceleration from AI usage is often just a placebo effect. - The AI Capabilities Model makes value contingent on seven systemic investments, including platforms, data ecosystems and strategy. For many organisations this means a multi-year transformation before they can get close to extracting real value from AI tooling. AI is not a silver bullet, it magnifies the strengths of already high-performing teams, while compounding the weaknesses of others. It is becoming clear that if your team and organisation are already practicing engineering excellence and have a strong, continuously improving product culture, you will benefit the most from AI adoption. If your organisations maturity is low, you are better off investing in foundational changes to your ways of working and culture first.

29

8 Comments

💡 AI doesn’t just change how code is written – it changes expectations and outcomes. In the final section of Jellyfish’s AI Adoption Guide, we explore how expectations for engineering leaders are evolving as AI becomes embedded across the SDLC. Because the organizations pulling ahead are treating AI as a transformation, not a tooling upgrade. Inside, you’ll explore: - Why AI adoption is quickly becoming a leadership mandate, not an option - How to balance ambitious goals with realistic expectations - What cultural investments are required to sustain long-term gains - How data can be used to align executives and engineering teams The teams that win in the AI era won’t just have better tools – they’ll have leaders who know how to guide change. Download today: https://lnkd.in/dut_6WpQ

21

1 Comment

new workflow pet peeve - proxying claude reviews e.g: - ash asks gary for review - gary asks claude for review - ash asks claude to fix feedback from review folks just set up claude to do the review and fix the code and have human reviews actually mean a human has had a look and agrees it's such a waste of time to proxy claude turns

6

1 Comment