Justy: Cody, I spent way too long this week going down a framework rabbit hole and then I read this piece that basically says — you probably don't need one.
Cody: Which one?
Justy: Shuai Guo, Towards Data Science. His whole argument: most LLM apps need a clear workflow, not an autonomous agent, and you can build it in plain Python.
Cody: Okay, that's… actually aligned with what we keep landing on. This is the harness thesis again.
Justy: Right? It's very ep five-fourteen — product is the harness, not the model. But this one's more pointed. He's saying the framework itself might be the wrong first abstraction.
Cody: Yeah.
Justy: Like, you start by picking CrewAI versus LangGraph versus whatever, spend hours comparing docs, and you haven't even written code yet.
Cody: And the real question he's asking is — do you even need an agent? Which is the thing Sydney Runkle was getting at with loop engineering too. If you already know the steps, why hand control to the model?
Justy: Exactly. He says for a lot of real problems, you know roughly how it should be solved. So define the steps yourself, use the LLM as a decision node inside the process, not the whole system.
Cody: Mm-hm.
Justy: And the wins are pretty concrete — workflows are transparent, modular, and the control flow is deterministic. The LLM can still reason inside a step, but the overall path is owned by code.
Cody: That's the part I actually buy. Deterministic control flow removes a whole class of debugging nightmares. You're not chasing why the agent decided to call tool X instead of Y — the path was already decided, you just need to check what the model did at that one node.
Justy: He walks through an anomaly explanation example, like a real use case — not toy stuff. And he says there's basically four ingredients you need.
Cody: Let me guess — control flow, system prompts, something for prompt construction, and structured output?
Justy: Yeah — role instructions, prompt builders, structured output. That's it. No framework. Just Python functions and the OpenAI Responses API.
Cody: I mean… he's right for the cases he's describing. If your problem decomposes into known steps with LLM calls at specific points, a framework is overhead. You're paying an abstraction tax for routing you could write in fifteen lines.
Justy: Right.
Cody: But here's where I'd push back — he's basically saying 'if you already know the graph, just write the graph.' That's true! But some problems genuinely don't have a known graph. The whole point of an agent is dynamic routing when you can't predefine the path.
Justy: And he admits that, to be fair. Says frameworks are clearly useful in some scenarios and he's not arguing they're bad.
Cody: Right, right. But the framing is still 'you probably don't need' — and I think the 'probably' is doing a lot of work there. If you're doing anything open-ended — research, debugging, multi-step exploration — you actually do need dynamic control.
Justy: I think the audience he's really talking to is the person who reaches for CrewAI on day one because they heard 'agents' and assume that's the architecture. Not someone who's already evaluated whether they need dynamic routing.
Cody: Sure.
Justy: And from the product side — I've seen this so many times. Someone picks a framework, builds around it, and then the framework's opinions about state or tool-calling become constraints they have to work around.
Cody: That's real. And it's the same thing we talked about with Flue — the framework should serve the workflow, not the other way around. Flue's whole pitch was zero lock-in and portable primitives.
Justy: The other thing he doesn't really address is what happens at scale. Like, okay, plain Python works for a prototype. But when you need persistence across restarts, recovery, multi-channel integration — that's where frameworks earn their keep.
Cody: Agreed. 'Just Python' starts to look a lot like a framework you built yourself, badly, at two AM.
Justy: That's every production system ever.
Cody: The honest version of this article is — start with a workflow, start in plain code, and only reach for a framework when the problem demands it. Not 'you probably don't need one,' but 'earn the abstraction before you adopt it.'
Justy: I like that better actually. Start simple, add complexity when you have evidence. That's just good product thinking.
Cody: Yeah.
Justy: Anyway — I'm going to go write some plain Python workflows now and pretend I never looked at those CrewAI docs.
Cody: Sure you are.