Paul examines the ongoing evolution of his coding workflow with large language models, emphasizing that effective collaboration with AI centers more on iterative questioning and adaptation than on static tools or rigid methodologies. He notes that initial reliance on graphical plugins often gives way to more streamlined, personally controlled approaches as users better understand AI’s capabilities
🎙️ Hosted by Paul at Talking to AI — where real people, real problems, and real conversations meet artificial intelligence.
Full Transcript
I am talking to AI.
A successful day, you don't need to know all the answers.
Just have good questions.
Chatting to AI is different from normal speech
and I hope you enjoy listening to the show
whilst getting ideas on how to pose your questions
to get the most out of AI.
My name is Paul.
The live conversations you hear are uncut
although sometimes the AI needs time to think.
In those cases, I've cut out the dead space.
Welcome.
So, I've been coding away for the last three months,
I guess, on various apps.
And I want to, this series of podcasts,
I'm going to be talking about some of the things
that I've learned.
And there's been a lot of things.
And I suppose the first thing I'm going to focus on
is going to be how my choice of tools has changed
over the last three months.
So, back in January, I was using VS Code.
And I had VS Code plugins.
I was using the Codex plugin
because I have a subscription to the Plus plan,
I think, with ChatGPT.
And I also tried a few other plugins.
I tried the…
I had the Kiro plugin.
And I think I had the cursor plugin as well.
And so, basically the way that was working
is that you've got this extra pane
that opens up in VS Code on the right
and you can code away.
Now, I've moved away from all these plugins in VS Code
and the main reason for it,
well, there's a couple of reasons.
One reason is that I don't really have the space
on my laptop to have a window open for a chat
and to be able to view my code.
So, I'd actually rather keep those in two desktops.
So, that's what I'm doing.
So, I've got…
I've now got…
I'm still using VS Code.
And that's primarily to review things
and also to create markdown files
and get them out and review markdown files.
But, I'm now using a separate app for the chat.
And I tried a variety of different apps
because I wanted a better workflow
and also sometimes I've been trying them
because I've run out of credits
and I'm going to try some free credits
or I'm just going to buy a membership for a month
or have a free month to try out different Adelands
and different agents.
And I don't know if I've tried them all,
but I've tried a lot of them in the last three months.
And I've ended up using a combination of VS Code
and Open Code, primarily, and Codex.
The command line interface for Codex.
So, I've gone command line for the chat,
but I'm still using VS Code to manage the repo.
I'm still actually using the terminal in VS Code
to make my own commits.
I'm not actually getting chat view pt
or whatever to commit for me.
That might be something I do in the future,
but I quite like having the control over it at the moment.
So, why have I ended up with what I have got?
So, one thing that the command line interface
allows you to do that the graphical chat windows did not
and maybe they do now,
is it allows you to just get it coding
and then it finishes when it finishes.
It's pretty annoying.
If I've got a repo and it's already connected to Git,
I can already do commits.
Anything that the LLM does in that repo,
if I don't like it,
I can just revert all of the changes and start again.
So, as long as it's only working in that repo,
I don't really care.
Just go ahead and blast away
and then I can review and see what's happening.
But a lot of those graphical interfaces,
they'll constantly ask you about whether they can do this,
whether they can do that,
and you just have to watch over them the whole time
while they're just doing stuff that you just want them to finish
so you can review it.
So, I found that the CLIs are great like that
because basically you just tell them what to do
and they'll just do it.
And that's the way I like it.
So, that's why I've gone one of the big reasons
for going to CI.
The other reason is, to be quite honest,
you only really need a text box anyway
when you're talking to chat GPT or Codex
or using, you know, it's all words anyway.
The only thing that I like to do
is I like to communicate via the terminal
and then I can use the visual studio code
to review the changes.
I can use visual studio code to review any documents
that might be created
and I can use it obviously to look at the code.
And that system is working quite nicely
so I have them on two different screens.
I've got plenty of space on both.
You know, I'm using multiple desktops on my Mac
so that I can just switch between the two.
So, if I'm running…
I'm often running more than one project at a time.
At the beginning of the year,
I was running about six at a time
and now it's gone down to two.
And maybe that's for another time.
I think that will be for another podcast
to actually explain something else there.
But with regards to my tools,
that's what I'm using.
I've tried Cursor.
I've tried Winsurf.
I've tried Kiro.
A core code, obviously.
So, anyway, I'll just go through those
and I'll just explain what I like
and what I didn't like about them
and why I didn't use them in yet.
And of course, you know, these are just my preferences.
So, I'll start with probably…
I'll start with Kiro
because that's maybe not a lot of people have used that.
When I started, I started using that in January
and they were giving away free credits.
And I think they still are.
So, it's free credits with Kiro.
And I really liked the idea of it to start with.
Basically, you know, as I'm developing with AI,
I'm finding that the old model
of sort of sprints and agile,
it's turning into…
Well, it's getting a bit more waterfall, isn't it?
It's getting a bit more into sort of,
here's your brief.
Well, this is it.
Yeah, it's exactly like that in a way.
I think there is still iteration involved.
But, you know, you've got
these two project management philosophies.
You've got agile, which is basically designed
for software development.
The main problem that solves is
it's very difficult to judge times
when you're doing software development.
Things often take a lot longer than you expect.
So, you have this concept of sprints
and a sprint is just like,
well, we've got a two-week sprint.
So, in two weeks, we're going to try and do this.
And at the end of the sprint,
we've got a bunch of functionality, hopefully,
but we might not have everything
that we put in the sprint.
So, that's okay.
And then we try and do it next time.
But with waterfall, you don't do that.
You basically say, here is a brief.
The brief is that we want to build an app
to do blah, blah, blah, blah.
The specification is we're going to do it like this.
And then let's build a plan.
And then let's do it.
And that's, that's,
and you don't traditionally have
the huge amount of iterations in waterfall.
Now, and it looks like we're going more than that way.
And so, the great thing about Kiro is that
it basically will, it's already set up
to create a bunch of documents for you.
So, it just creates the documents.
You know, and that was super cool back in January,
but things changed so much.
And to be honest,
I thought it was super cool when I started using it,
but then it's, then I sort of started working differently.
And I wanted to create the documents the way I wanted to create.
And so I stopped using Kiro's plans.
And then I think I ran out of credits anyway,
and went back onto Codex.
So, I, so that was Kiro.
I never bought any credits for Kiro.
Then WinSurf, WinSurf was similar.
I didn't, WinSurf and Kiro, the things I,
the biggest problems with WinSurf and Kiro
is that they have this feature where, you know,
they try to constantly nag you about,
should I do this, should I do that,
can't do this, can't do that.
Now, it might be that I can turn all that off,
but I didn't really, I didn't like that,
and I didn't like, I didn't like Kiro,
the fact that it is integrated with VS Code.
And to be honest, I'm better off just using VS Code.
How many VS Code clones do I want on my laptop?
So, there was a bit of that.
And the same thing with WinSurf, really,
like it was similar, very similar to Kiro,
I would have said.
Cursor was, seems to be pretty good value,
the subscription, I got a subscription,
I seem to get quite a bit for my subscription.
But I didn't, at the time,
I don't think they had a command line interface either.
So, after a while, basically what happened was
I was working and then I downloaded Claude Code,
and I started using Claude Code,
and then Claude Code is really good.
So, Claude Code is another agent,
and then it can run a lens,
but I think it mainly just runs the anthropic Claude,
and the interface is good.
The interface, so it's good because it will just do
what you ask it to do, first thing.
It's good because it's just the text,
because it's a terminal,
but the terminal actually works quite nicely.
It's not an ugly interface.
And what else do I like about it?
What else I like about Claude Code?
It gives you a lot more information
about what's going on with your token usage.
So, you could use Claude Code quite actively
and try to…
So, a theme that's been going through my working with LLMs
is to try to understand exactly how it works.
Like, what is in its brain
when I ask it to do something?
And that is not always a particularly obvious thing.
And knowing when it's running out of context window
and stuff like that is useful.
And it has some very good tools in Claude Code
to manage the context window.
So, I like that at Claude Code.
The reason I'm not using it is because it's just…
It's just expensive, basically.
You get through credits in no time,
and then you're done.
But on the other side,
I do think that the Opus LLM is less.
So, yes.
So, currently, my setup is I'm paying for Codex,
and I've also got an API.
I'm using Open Code with Open Router,
and I've got a $10 subscription on Open Router.
And basically, I use that subscription
when I want to use Claude Opus.
And I use Claude Opus really only
for planning complicated things
because it is the best for that.
So, that's my…
So, I am still using Claude a little bit.
But the majority of the coding that I'm doing
now is using Open Code with…
I'm actually using the free LLM at the moment.
Yeah, I would have thought that I would be going back to Codex,
so I'm paying for Codex.
But I have to say Minimax N2x5,
which is free with Open Code,
is pretty good.
I keep on going between Codex with Chachi BT
and Minimax,
and I'm not really finding a lot of difference
in its abilities.
Although, yes, I think Codex is more…
Not Codex, but the Chachi BT models are more capable,
but it really depends on how you're using the whole stuff,
all the stuff as to whether, you know,
how capable you need.
And I think that's probably a subject for another…
Maybe the next episode,
because I suppose one thing that…
Before I get onto that, let me just outline.
So, my current setup is Open Code,
Open Router for the API for Claude.
I'm paying for Codex,
and I'm using Minimax,
which is a free LLM with Open Code.
Oh, yes, I did dabble with local routers.
I've also got a LLAMA on my machine.
So, it's only…
My machine's only got 16 gigs of RAM,
so it can't run, you know,
anything like the kind of models that I'm running,
like Minimax or Chachi BT.
I've got Quaint 2.5 Coder 7D,
but I can run locally on my machine.
But, to be honest,
I think it's not super useful,
not compared to the other models.
It takes too much micro-managing to get it to be useful.
I do think it could be useful
if the agent managed it in a certain way.
Maybe if I could use it in conjunction with some other models,
you know, where it uses a more powerful model
for the coordination,
and then it uses that one for the smaller level items.
But, yes, I'm not using that.
So, and my way of working…
Yeah, so my way of working, that's kind of relevant,
has changed as well.
So, as I said before, I was using Kiro to start with.
And, well, I wasn't using Kiro, I was using Chachi BT,
but then I started on Kiro and I thought,
wow, this is cool, like, creating all these documents.
And, of course, that's the way everyone's doing stuff now anyway.
They probably were in January as well,
but that was me learning how you're supposed to do these things.
And then I created my own process for doing those documents,
which involved a bunch of markdown files.
In the last month, I've learned really how to use skills in these agents.
And that's sort of changed the way I'm working quite a bit,
because if you imagine you've got a bunch of tasks
that you need to do on a regular basis,
a skill is nothing very complicated,
it's just a prompt which you use to do a task.
But the good thing about a skill is that you can sort of fine-tune that over time.
And that's really the way you're supposed to work with LLM.
So, all of the sort of process that you use,
whenever it works and or you think,
oh, this could be improved, you obviously want to change,
you want to change it for now,
but you want to change it for the future.
So, if there are architectural things that you discover need to change
in the way that the app that you're working on is working,
a much better way of working is to fix that,
but also fix the guidance in the app so that it doesn't happen again.
And that's not always as simple as I think it should be.
And that requires that you understand how you've set up your various rules files
or context files depending on what LLM you're using.
And I'm sort of moving away from having too many of these context files
and rules files in my repo
and trying to use more skills instead
because if you have a lot of, say, agents DB files throughout your repo,
then you're going to cause the LLM to read a whole bunch of stuff before it starts
and the LLM is not necessarily going to need to read all of that stuff.
You can try to put sort of conditionals in the documents,
but the LLM doesn't work very well with logic within these markdown files.
If you say, well, if you're doing this, go to here.
If you're doing this, go to here. That doesn't really work very well.
So, a better way of doing it is if you wanted to do something,
just save a skill and then invoke that skill when you're actually doing it.
So, I've got a skill for creating a plan.
I've got a skill for sort of troubleshooting.
I've got a refactor skill and a bunch of other skills.
But the plan one, the refactor, is being used quite a bit at the moment.
And I can see how that's going to just increase.
So, it's meaning that my, I suppose my, the way I imagine working with LLM
at the beginning of the year was that you basically, all you've got to do is just sort of
set it up in the right way, give it the right advice that it gets at the right time
and then it does the right thing.
But now, I'm sort of coming, I'm having to be more involved, I guess.
And that way, and not rely on that kind of approach so much as if I wanted to do something,
I actually have to put the work up front.
I can't really expect, I shouldn't, well, it's not necessarily going to work
if I'm just thinking that I've got this, you know, coding style document
and it's always going to read that, probably isn't.
So, if I want it to do specific things, I have to specifically be specific about it.
So, what it means is I just have to do more work than I thought.
But the good thing about that is it means that I'm more useful than I thought in January.
So, I've sort of gone off the subject there, but that was supposed to be about the tools that I'm using
and why I'm using them and I think that covers it.
So, next time, I'll expand a bit more on this sort of idea around what a human being's good for
when it comes to programming and I think my attitude has definitely hardened up
that they're actually pretty damn useful.
So, that's all from me.
I hope you enjoyed this.
I hope I didn't ramble on too much and goodbye.
For show notes and more, go to talking2ai.show.