This sounds like a genuinely awful way to work.
No Coding Before 10am
11–20 of 58 posts
Re: No Coding Before 10am
#12lol. my personal preference has always to do ALL the coding as early as possible. i get progressively dumber as the day wears on, seems sad to waste the prime hours on meetings and other more human things. I don't see how that would change if you accept the premise that code is now a commodity.
That is essentially what the article says, that mornings are the most productive time, but it has shifted the focus from you doing the work, and mostly in the morning, to you outlining the work clearly in the morning, and the agent doing the work all day (and all night, and while you commute, and while you are in meetings)
Re: No Coding Before 10am
#13lol. my personal preference has always to do ALL the coding as early as possible. i get progressively dumber as the day wears on, seems sad to waste the prime hours on meetings and other more human things. I don't see how that would change if you accept the premise that code is now a commodity.
Not linear in my case. My best is somewhere around 11ish. So that's usually when I start my ballmer peak and take my first beer. (Joking, of course, for people who don't get the reference)
Re: No Coding Before 10am
#14Coding tools are less stable as the code grows for several reasons.
Some recent techniques claim to be solving this problem but none reached a release yet.
Working with what we have now, this is a recipe for disaster. Agents often lies about the outputs. The shorter the context space they have to manage while the bigger the data already in context makes it prone to lie and deceive.
It works ok for small changes on top of human code. That's what we know works now. The rest is more yet to be reached
Re: No Coding Before 10am
#15It has always been like this.
Plan before you code. Now your plan is just in a prompt.
Re: No Coding Before 10am
#16> Don’t spec the process, spec the outcome.
For this, which summarises vibe coding and hence the rest of the article, the models aren't good enough yet for novel applications.
With current models and assuming your engineers are of a reasonable level of experience, for now it seems to result in either greatly reduced velocity and higher costs, or worse outcomes.
One course correction in terms of planned process, because the model missed an obvious implication or statement, can save days of churning.
The math only really has a chance to work if you reduce your spend on in-house talent to compensate, and your product sits on a well-trodden path.
In terms of capability we're still at "could you easily outsource this particular project, low touch, to your typical software farm?"
Re: No Coding Before 10am
#17> If 10x more tokens saves a day, spend the tokens. The bottleneck is human decision-making time, not compute cost. This seems entirely backwards. Why spend money to optimize something that _isn't_ the bottleneck?
I'm not sure I agree with this. 10x more tokens means leaaving the agent to work for 10x longer, which may lead to bugs and misintepretation of the intention. Breaking the goal into multiple tasks seems more efficient in terms of tokens and getting close to the desired goal. Of course this means more human involvment, but probably not 10x more.
Re: No Coding Before 10am
#18lol. my personal preference has always to do ALL the coding as early as possible. i get progressively dumber as the day wears on, seems sad to waste the prime hours on meetings and other more human things. I don't see how that would change if you accept the premise that code is now a commodity.
This kind of generalizations are very organization specific because they rely on preexisting rules set within company. I dismiss every such rule and work that forces me to adjust my daily routine too heavily. Let me choose my best ways to deliver more instead of trying to fit me in the box.
In these cases, I just read the main point behind in this case is "create a way for devs to share context when working with AI".
Re: No Coding Before 10am
#19"Agents should work overnight, on commutes, in meetings, asynchronously."
If I read stuff like that, I wonder what the F they are doing. Agents work overnight? On what? Stuck in some loop, trying to figure out how to solve a bug by trial and error because the agent isn't capable of finding the right solution? Nothing good will come out of that. When the agent clearly isn't capable of solving an issue in a reasonable amount of time, it needs help. Quite often, a hint is enough. That, of course, requires the developer to still understand what the agent is doing. Otherwise, most likely, it will sooner or later do something stupid to "solve" the issue. And later, you need to clean up that mess.
If your prompt is good and the agent is capable of implementing it correctly, it will be done in 10 minutes or less. If not, you still need to step in.
Re: No Coding Before 10am
#20The points look like disconnected pieces of wisdom, rather than tied to some common goals or objectives. First get clarity on root objectives, roles (who is doing what), artifacts etc and then define rules that are immediately traceable to the objectives, roles and artifacts.