Vibe coding, after the honeymoon

spinny:~/writing $ vim 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~

NORMAL · vibe-coding-agentic-engineering.md [readonly]162 lines · :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?

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~