The Internets are ripe with videos and blog posts telling you that you're doing it all wrong. This isn't really different from anything we've ever seen in technology. People understandably want to sell themselves and appear valuable. But in the last two years or so, I've found that agentic coding involves using a lot of what you might have already been doing.
The overwhelming sentiment is to create more stuff so that Claude gets more right. And then check it when it's done anyway to make sure. For all of the anthropomorphizing that people do with AI, maybe they don't do it enough. I've had pretty good results, and speed, just doing what I already expected to do with humans.
This is the part where I remind people that the longest part of product development is deciding what to do, not how to do it. As engineers will tell you, a lot of our time is spent reducing ambiguity, and getting into fast feedback cycles so we build the right thing. And if you manage engineers, you know that telling them to do something and come back when it's done is disastrous. Yet, this seems to be what people want AI to do. Great, you spun up a dozen agents in parallel, cool story, but was that the goal or requirement? Of course not.
To seed a project, I direct the machine to setup a certain structure, generate some YAML for builds and whatever, and then write how I think the project should be built architecturally in the CLAUDE.md file. I break it up between the natural boundaries of system components. So that means there's usually some kind of API project that's just plumbing to business logic and service classes. I have bits that bridge those to databases, caches, message buses and such. Then I figure out what is the smallest possible thing that I can build, and have it do that, broken up the same way I would for humans, basically creating tasks in each of the above areas.
Feature work goes the same way, splitting it up into the component bits, doing each one, reviewing each batch of changes. For example, direct messaging took about two hours when I added it to TogetherLoop. It's a great example of using the tool to fill in my knowledge gaps. The trick isn't schema or business logic or web sockets, all of which are easy enough to describe and get solid output. But there are a dozen rules around scrolling that I didn't think about, and wouldn't have known how to code without research. It took awhile to get it right, and produce serviceable code, but it was faster than me trying to figure it out. (Full disclosure: I built a similar feature many years ago in POP Forums, manually, and it took a few nights of work.)
What I'm getting at is that this is no different than the way I would treat pairing with others or planning out how to execute something with a team. Yes, Claude does some really stupid things, and is overconfident in its assessments, but you see it, you redirect and you move on. Trying to get it right the first time seems like a colossal waste of time. Fast iteration and doing the next right thing gets you there fast without trying to box it in with pages of text.
No comments yet.