Vibe coding, after the honeymoon

spinny:~/writing $ less vibe-coding-agentic-engineering.md

1 
2Vibe coding is one of those expressions that seem born to be hated and then, slowly, become useful.
3 
4At first it sounds like: I don't think, I ask the AI, I accept what comes out, keep going. A cheerful way to produce technical debt with a musical background.
5 
6But it would be too easy to dismiss it like that. The truth is that vibe coding has intercepted a real thing: programming with a model changes the relationship between idea and prototype.
7 
8First you had a thought and then a long climb. Now often you have a thought and half an hour later something moves on the screen. It's hard not to be seduced by it.
9 
10The interesting question, in 2026, is not whether vibe coding is true. It is. The question is: what happens after the honeymoon?
11 
12## The prototype has become economical
13 
14This is the most important part.
15 
16AI tools have lowered the emotional cost of getting started. Before, if you wanted to try an idea, you already had to put in the work: choose stack, create project, remember boilerplate, write layout, connect APIs, wrangle with boring details.
17 
18Now you can say: give me a first version.
19 
20And a first version arrives.
21 
22Not always beautiful. Not always correct. Often fragile. But it comes. And when it arrives, it changes the conversation. You are no longer arguing in a vacuum. You're touching something.
23 
24This is very powerful for designers, founders, product managers, senior developers tired of rewriting scaffolding, curious people who wouldn't have opened an editor before.
25 
26Vibe coding is hype because it gives more people the physical sensation of the software being created.
27 
28## The problem is that the software lives on
29 
30The part that the meme tells the least is the day after.
31 
32The prototype must be read. Correct. Tested. Deployed. Secured. Got it from someone else. Connected to real data. Made accessible. Maintained when a dependency changes.
33 
34Here pure vibe coding hits the wall.
35 
36A model can generate a lot of code quickly, but code is not value in itself. It is a promise of behavior. And a promise must be verified.
37 
38The risk of vibe coding isn't writing ugly code. We have always done it even without AI. The risk is losing the sense of ownership: "the model did it" becomes an excuse for not understanding enough.
39 
40But the runtime doesn't accept excuses. If the code runs in production, it's yours.
41 
42## From vibe coding to agentic engineering
43 
44The mature version of vibe coding is not to stop using agents. It is to use them with a more serious cycle.
45 
46Not: it generates everything and we hope.
47 
48But:
49 
501. describe the intention;
512. let generate a draft;
523. ask the agent to explain the plan;
534. make small diffs;
545. launch tests;
556. do reviews;
567. correct;
578. only then join.
58 
59This thing deserves a different name. I like agent engineering, even if it sounds a bit solemn. It means using agents not as slot machines, but as collaborators within an engineering process.
60 
61The point is not to take energy away from vibe coding. It's giving her tracks.
62 
63## Where it works great
64 
65Vibe coding works when the cost of error is low and the value of exploration is high.
66 
67Examples:
68 
69- interface prototypes;
70- personal tools;
71- internal dashboards;
72- small games;
73- one-time script;
74- API scans;
75- proof of concept;
76- mechanical refactors with good tests;
77- technical contents to be transformed into demos.
78 
79In these cases speed is the point. You want to see if the idea has legs. You want to find out what you didn't understand. You want to get to a concrete conversation.
80 
81Vibe coding is perfect for making form emerge.
82 
83## Where it gets dangerous
84 
85It becomes dangerous when the system has consequences and no one slows down.
86 
87Payments, personal data, auth, permissions, infrastructure, database migrations, sensitive legacy code, compliance, production. Here the vibe is not enough. We need rigor.
88 
89It doesn't mean AI can't help. In fact, it can help a lot. But it must work within narrow confines: branch, sandbox, test, lint, review, feature flag, rollback.
90 
91The phrase to be tattooed on the monitor is simple: the faster the agent, the more readable the process must be.
92 
93If you can't explain what's changed, you haven't accelerated. You just shifted the debt from time to understanding.
94 
95## The new role of the developer
96 
97The most interesting part is that the developer's job doesn't disappear. Change density.
98 
99Less time on boilerplate. More time on intention, decomposition, review, integration, testing, boundaries.
100 
101The developer becomes a kind of technical editor. Not in the lame sense of “proofreads.” In the strong sense: it decides what must exist, what must be cut, what is consistent with the system, what deserves trust.
102 
103A good editor doesn't take everything they get. He doesn't even rewrite it all out of pride. Recognizes good material, brings it to form, protects the reader.
104 
105With agents, the reader is also the future maintainer. Often that's you in three weeks.
106 
107## The pattern I see emerging
108 
109The healthiest pattern is this:
110 
111- human: intention, constraints, taste, responsibility;
112- agent: variants, scaffolding, search, local modifications, repetitive tests;
113- infrastructure: sandbox, CI, trace, permissions, deployment;
114- team: review, ownership, standards.
115 
116When one of these pieces is missing, something becomes deformed.
117 
118Only human: slow, often bogged down by repetitive work.
119 
120Agent only: fast, but without situated judgment.
121 
122Just infrastructure: Elegant process for producing useless things.
123 
124Team only: very orderly meetings around a prototype that never arrives.
125 
126The best happens when the pieces talk to each other.
127 
128## A small checklist
129 
130Before letting a vibe-coded prototype grow, I would ask myself these questions:
131 
132- do I understand the structure of the code?
133- are there tests for critical behavior?
134- do I know which files the agent touched?
135- have I removed code generated but not used?
136- have any secrets, tokens or fake data ended up in the wrong place?
137- is the minimum accessibility respected?
138- does the deployment have rollback?
139- can anyone besides me keep it?
140 
141If the answer is no to too many questions, it's not a failure. It's just a prototype that needs to remain a prototype a little longer.
142 
143## My reading
144 
145Vibe coding is a loud word for a tender thing: the joy of seeing an idea take shape before fear stops it.
146 
147I don't want to throw it away. That would be snobbish. Many good things are born like this, half crooked and alive.
148 
149But the remaining software needs more. It needs understanding, testing, ownership, infrastructure, boundaries. It needs someone to say: cool, now let's make it real.
150 
151Maybe the future isn't about choosing between "seriously" programming and "vibe" programming. Maybe it's learning to change gear: explore lightly, then consolidate with respect.
152 
153The human part is there. Know when to run and when to sit and read the diff.
154 
155## Sources
156 
157- [Simon Willison: Not all AI-assisted programming is vibe coding](https://simonwillison.net/2025/Mar/19/vibe-coding/)
158- [OpenAI: How people are using ChatGPT](https://openai.com/index/how-people-are-using-chatgpt/)
159- [GitHub Blog: GitHub Copilot coding agent](https://github.blog/ai-and-ml/github-copilot/introducing-github-copilot-coding-agent/)
160- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
161- [Stack Overflow Blog: Why vibe coding is the future](https://stackoverflow.blog/2025/04/21/why-vibe-coding-is-the-future/)
162

:Vibe coding, after the honeymoonlines 1-162 (END) — press q to close

2Vibe coding is one of those expressions that seem born to be hated and then, slowly, become useful.

4At first it sounds like: I don't think, I ask the AI, I accept what comes out, keep going. A cheerful way to produce technical debt with a musical background.

6But it would be too easy to dismiss it like that. The truth is that vibe coding has intercepted a real thing: programming with a model changes the relationship between idea and prototype.

8First you had a thought and then a long climb. Now often you have a thought and half an hour later something moves on the screen. It's hard not to be seduced by it.

10The interesting question, in 2026, is not whether vibe coding is true. It is. The question is: what happens after the honeymoon?

12## The prototype has become economical

14This is the most important part.

16AI tools have lowered the emotional cost of getting started. Before, if you wanted to try an idea, you already had to put in the work: choose stack, create project, remember boilerplate, write layout, connect APIs, wrangle with boring details.

18Now you can say: give me a first version.

20And a first version arrives.

22Not always beautiful. Not always correct. Often fragile. But it comes. And when it arrives, it changes the conversation. You are no longer arguing in a vacuum. You're touching something.

24This is very powerful for designers, founders, product managers, senior developers tired of rewriting scaffolding, curious people who wouldn't have opened an editor before.

26Vibe coding is hype because it gives more people the physical sensation of the software being created.

28## The problem is that the software lives on

30The part that the meme tells the least is the day after.

32The prototype must be read. Correct. Tested. Deployed. Secured. Got it from someone else. Connected to real data. Made accessible. Maintained when a dependency changes.

34Here pure vibe coding hits the wall.

36A model can generate a lot of code quickly, but code is not value in itself. It is a promise of behavior. And a promise must be verified.

38The risk of vibe coding isn't writing ugly code. We have always done it even without AI. The risk is losing the sense of ownership: "the model did it" becomes an excuse for not understanding enough.

40But the runtime doesn't accept excuses. If the code runs in production, it's yours.

42## From vibe coding to agentic engineering

44The mature version of vibe coding is not to stop using agents. It is to use them with a more serious cycle.

46Not: it generates everything and we hope.

48But:

501. describe the intention;

512. let generate a draft;

523. ask the agent to explain the plan;

534. make small diffs;

545. launch tests;

556. do reviews;

567. correct;

578. only then join.

59This thing deserves a different name. I like agent engineering, even if it sounds a bit solemn. It means using agents not as slot machines, but as collaborators within an engineering process.

61The point is not to take energy away from vibe coding. It's giving her tracks.

63## Where it works great

65Vibe coding works when the cost of error is low and the value of exploration is high.

67Examples:

69- interface prototypes;

70- personal tools;

71- internal dashboards;

72- small games;

73- one-time script;

74- API scans;

75- proof of concept;

76- mechanical refactors with good tests;

77- technical contents to be transformed into demos.

79In these cases speed is the point. You want to see if the idea has legs. You want to find out what you didn't understand. You want to get to a concrete conversation.

81Vibe coding is perfect for making form emerge.

83## Where it gets dangerous

85It becomes dangerous when the system has consequences and no one slows down.

87Payments, personal data, auth, permissions, infrastructure, database migrations, sensitive legacy code, compliance, production. Here the vibe is not enough. We need rigor.

89It doesn't mean AI can't help. In fact, it can help a lot. But it must work within narrow confines: branch, sandbox, test, lint, review, feature flag, rollback.

91The phrase to be tattooed on the monitor is simple: the faster the agent, the more readable the process must be.

93If you can't explain what's changed, you haven't accelerated. You just shifted the debt from time to understanding.

95## The new role of the developer

97The most interesting part is that the developer's job doesn't disappear. Change density.

99Less time on boilerplate. More time on intention, decomposition, review, integration, testing, boundaries.

100

101The developer becomes a kind of technical editor. Not in the lame sense of “proofreads.” In the strong sense: it decides what must exist, what must be cut, what is consistent with the system, what deserves trust.

102

103A good editor doesn't take everything they get. He doesn't even rewrite it all out of pride. Recognizes good material, brings it to form, protects the reader.

104

105With agents, the reader is also the future maintainer. Often that's you in three weeks.

106

107## The pattern I see emerging

108

109The healthiest pattern is this:

110

111- human: intention, constraints, taste, responsibility;

112- agent: variants, scaffolding, search, local modifications, repetitive tests;

113- infrastructure: sandbox, CI, trace, permissions, deployment;

114- team: review, ownership, standards.

115

116When one of these pieces is missing, something becomes deformed.

117

118Only human: slow, often bogged down by repetitive work.

119

120Agent only: fast, but without situated judgment.

121

122Just infrastructure: Elegant process for producing useless things.

123

124Team only: very orderly meetings around a prototype that never arrives.

125

126The best happens when the pieces talk to each other.

127

128## A small checklist

129

130Before letting a vibe-coded prototype grow, I would ask myself these questions:

131

132- do I understand the structure of the code?

133- are there tests for critical behavior?

134- do I know which files the agent touched?

135- have I removed code generated but not used?

136- have any secrets, tokens or fake data ended up in the wrong place?

137- is the minimum accessibility respected?

138- does the deployment have rollback?

139- can anyone besides me keep it?

140

141If the answer is no to too many questions, it's not a failure. It's just a prototype that needs to remain a prototype a little longer.

142

143## My reading

144

145Vibe coding is a loud word for a tender thing: the joy of seeing an idea take shape before fear stops it.

146

147I don't want to throw it away. That would be snobbish. Many good things are born like this, half crooked and alive.

148

149But the remaining software needs more. It needs understanding, testing, ownership, infrastructure, boundaries. It needs someone to say: cool, now let's make it real.

150

151Maybe the future isn't about choosing between "seriously" programming and "vibe" programming. Maybe it's learning to change gear: explore lightly, then consolidate with respect.

152

153The human part is there. Know when to run and when to sit and read the diff.

154

155## Sources

156

157- [Simon Willison: Not all AI-assisted programming is vibe coding](https://simonwillison.net/2025/Mar/19/vibe-coding/)

158- [OpenAI: How people are using ChatGPT](https://openai.com/index/how-people-are-using-chatgpt/)

159- [GitHub Blog: GitHub Copilot coding agent](https://github.blog/ai-and-ml/github-copilot/introducing-github-copilot-coding-agent/)

160- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

161- [Stack Overflow Blog: Why vibe coding is the future](https://stackoverflow.blog/2025/04/21/why-vibe-coding-is-the-future/)

162