I made a post about this the other day! I think it's a sliding scale – you can use agentic coding in a more-professional or less-professional way.
Post as follows:
—
I have a take on vibe-coding for professionals. TL;DR: If you’re not loving AI editors, you’re probably doing it wrong.
Vibe-coding isn’t just for mock-ups.
It pains me when I hear high-level SWEs say that LLMs are only good for projects ‘up until a point,’ before it all supposedly falls apart.
—
I use Cline. It’s the dark horse of AI code editing. It’s an open source VS Code plugin and you should absolutely try it.
The best part about Cline is that it forces you to think about PLANNING and ACTING as two distinct phases. When I meet people who don’t love AI coding, it’s usually because they stay in the equivalent of ACT mode the whole time.
(Other IDEs are capable of doing this, too, to varying degrees. Cline just makes it very explicit.)
If you’re not spending at least 4x the amount of time PLANNING vs. ACTING in your AI code editor, you’re probably doing it wrong!
The best engineers will spend more than 20 minutes planning before they unleash AI to make any changes whatsoever.
If you’re one-shotting absolutely everything, you’re absolutely doing it wrong. When you try to one-shot complex changes, the AI is going to mess them up. And it’s going to take forever for you to have the opportunity to intervene.
This is where people get really frustrated: ‘I have to wait forever, and then the code is completely wrong anyway.’
The better approach is to treat Cline like a thought-partner. ‘Let’s add this class.’ And then review the plan before it submits one line of code. It’ll say, ‘I’m thinking of doing it this way,’ or ‘I’ll use this library.’ It’s often wrong – but that’s okay, it’s a quick turn-around to nudge it back on track and nothing’s set in stone in PLAN mode!
That’s when you have the opportunity to coax the AI into doing something more salient. And after three or four back-and-forth exchanges, you’ll have a really great plan for how Cline should execute.
Then you’ll press ACT, and go make a coffee. Most of the time, when you come back, it’ll have finished with near-perfect edits across many files.
And that’s it! If you do that, you should be able to leverage your years of experience, and your AI coding partner will do all the busy work, while you’re thinking through edge cases and architecture.
If I have to spend all that time planning on how to phrase my stuff to the chatbot, then I might as well think about the code I'm about to write and write it myself. That way I don't have to keep reviewing code I didn't write. Even if the chatbot says it's going to do this or that particular approach, that has absolutely no bearing on the generated code. Every single line must be carefully scrutinized anyway.
Reading code is a lot harder than writing it. Describing it to a "junior programmer" and then reading and scrutinizing the code is even harder. Especially because of the edge cases that you don't know if the chatbot tackled them, and if not where to fix them. Special cases tend to be subtle, so you'd need to be extra careful when trying to understand the code (which you didn't write).
And if, when coding, you think that coding is the boring part, then you are doing it wrong :)
"vibe" and "professional" don't go in the same sentence.
I made a post about this the other day! I think it's a sliding scale – you can use agentic coding in a more-professional or less-professional way.
Post as follows:
—
I have a take on vibe-coding for professionals. TL;DR: If you’re not loving AI editors, you’re probably doing it wrong.
Vibe-coding isn’t just for mock-ups.
It pains me when I hear high-level SWEs say that LLMs are only good for projects ‘up until a point,’ before it all supposedly falls apart.
—
I use Cline. It’s the dark horse of AI code editing. It’s an open source VS Code plugin and you should absolutely try it.
The best part about Cline is that it forces you to think about PLANNING and ACTING as two distinct phases. When I meet people who don’t love AI coding, it’s usually because they stay in the equivalent of ACT mode the whole time.
(Other IDEs are capable of doing this, too, to varying degrees. Cline just makes it very explicit.)
If you’re not spending at least 4x the amount of time PLANNING vs. ACTING in your AI code editor, you’re probably doing it wrong!
The best engineers will spend more than 20 minutes planning before they unleash AI to make any changes whatsoever.
If you’re one-shotting absolutely everything, you’re absolutely doing it wrong. When you try to one-shot complex changes, the AI is going to mess them up. And it’s going to take forever for you to have the opportunity to intervene.
This is where people get really frustrated: ‘I have to wait forever, and then the code is completely wrong anyway.’
The better approach is to treat Cline like a thought-partner. ‘Let’s add this class.’ And then review the plan before it submits one line of code. It’ll say, ‘I’m thinking of doing it this way,’ or ‘I’ll use this library.’ It’s often wrong – but that’s okay, it’s a quick turn-around to nudge it back on track and nothing’s set in stone in PLAN mode!
That’s when you have the opportunity to coax the AI into doing something more salient. And after three or four back-and-forth exchanges, you’ll have a really great plan for how Cline should execute.
Then you’ll press ACT, and go make a coffee. Most of the time, when you come back, it’ll have finished with near-perfect edits across many files.
And that’s it! If you do that, you should be able to leverage your years of experience, and your AI coding partner will do all the busy work, while you’re thinking through edge cases and architecture.
*chef’s kiss*
If I have to spend all that time planning on how to phrase my stuff to the chatbot, then I might as well think about the code I'm about to write and write it myself. That way I don't have to keep reviewing code I didn't write. Even if the chatbot says it's going to do this or that particular approach, that has absolutely no bearing on the generated code. Every single line must be carefully scrutinized anyway.
Reading code is a lot harder than writing it. Describing it to a "junior programmer" and then reading and scrutinizing the code is even harder. Especially because of the edge cases that you don't know if the chatbot tackled them, and if not where to fix them. Special cases tend to be subtle, so you'd need to be extra careful when trying to understand the code (which you didn't write).
And if, when coding, you think that coding is the boring part, then you are doing it wrong :)