lol. 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.
Coding 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
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?"
"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.
The 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.
> Code is context, not a library. Data is the real interface.
I don't *yet* subscribe to the idea of "code is context for AI, not an interface for a human", but I have to admit that the idea sounds feasible. I have many examples of small-to-mid size apps (local use only) where I pretty much didn't even look at the code beyond checking that it doesn't do anything finicky. There, the code doesn't mater because I know that I can always regenerate it from my specs, POC-s, etc. I agree that the paradigm changes completely if you look at code as something temporary that can be thrown away and re-created when the specification changes. I don't know where this leads to and if this is good or not for our industry, but the fact is - it is feasible.
I would never use this paradigm for anything related to production, though. Nope. Never. Not in the foreseeable future anyway.
> Everyone uses their own IDE, prompting style, and workflow.
In my experience with recent models this is still not a good idea: it quickly leads to messy code where neither AI nor human can do anything anymore. Consistency is key. (And abstractions/layers/isolation everywhere, as usual).
IDE - of course. But, at the very least, I would suggest using the same foundation model across the code base, .agent/ dirs with plenty of project documents, reusable prompts, etc.
--
P.S. Still not sure what does the 10AM rule bring, though...
Anyone else find reading things like this slightly exhausting?
I'm very much pro AI for coding there are clearly significant capabilities there but I'm still getting my head around how to best utilise it.
Posts like these make it sound like ruthlessly optimizing your workflow letting no possible efficiency go every single day is the only way to work now. This has always been possible and generally not a good idea to focus on exclusively. There's always been processes to optimise and automate and always a balance as to which to pursue.
Personally I am incorporating AI into my daily work but not getting too bogged down by it. I read about some of the latest ideas and techniques and choose carefully which I employ. Sometimes I'll try and AI workflow and then abandon it. I recently connected Claude up to draw.io with an MCP, it had some good capabilities but for the specific task I wanted it wasn't really getting it so doing it manually was the better choice to achieve what I wanted in good time.
The models themselves and coding harnesses are also evolving quickly complex workflows people may put together can quickly become pointless.
Sounds like GPT wrote this piece based on some tech exec‘s „we must use AI or lose“ „strategy“. Just let engineers use the tools they want instead of force feeding them yet another ridiculous process. For me, if I have to do meetings in the morning (or „write promps“ lmao) instead of clearing out the ridiculous AI slop debt of code agents my product would never ship.
So if you specify work the right way, you can move at incredible velocity. If you have the confidence in your setup and ways of working, you don’t need to look at the code being put out.
Genuinely seeking answers on the following - if you’re working that way, what are you “understanding” about what’s being produced? Are you monitoring for signal that points out gaps in your spec which you update; code base is updated, bugs are fixed and the show goes on? What insights can you bring to how the code base works in reality?
Not a sceptic, but thinking this stuff through ain’t easy!
It blows my mind how these posts seem like everyone is victim of a collective amnesia.
Literally every single point in the article was good engineering practice way before AI. So it's either amnesia or simple ignorance.
In particular, "No coding before 10am" is worded a bit awkward, as it simply means "think before you write code", which... Does it need an article for saying it?
The spec prompts are typically better off being reviewed iteratively using AI itself, a lot more so than merely by pairing with coworkers. Perhaps a combination is best. The point is that AI reviews of the task spec must never be overlooked prior to its execution.
Also, if your spec is taking too long for the agent to execute, odds are high that it's ambiguous, unsound, unreviewed, underspecified, unmaintainable, or the model is just optimized to waste tokens so as to bill you maximally.
This vision of "no coding before 10am" captures an exciting shift—but it also raises important questions about correctness, maintainability, and the enduring role of human judgment in software.
I've been reflecting on these ideas (especially the claim that "code is context, not a library" and that you should "review the output, not the code") and wrote a response exploring why craftsmanship, elegance, and deep understanding still matter—even, or especially, in an AI-native workflow:
22 comments
[ 3.0 ms ] story [ 41.9 ms ] threadThis seems entirely backwards. Why spend money to optimize something that _isn't_ the bottleneck?
My team is incredibly clueless and complacent. I can't even get them to use TypeScript or to migrate from Yarn v1.
I don't see how that would change if you accept the premise that code is now a commodity.
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
Plan before you code. Now your plan is just in a prompt.
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?"
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.
I don't *yet* subscribe to the idea of "code is context for AI, not an interface for a human", but I have to admit that the idea sounds feasible. I have many examples of small-to-mid size apps (local use only) where I pretty much didn't even look at the code beyond checking that it doesn't do anything finicky. There, the code doesn't mater because I know that I can always regenerate it from my specs, POC-s, etc. I agree that the paradigm changes completely if you look at code as something temporary that can be thrown away and re-created when the specification changes. I don't know where this leads to and if this is good or not for our industry, but the fact is - it is feasible.
I would never use this paradigm for anything related to production, though. Nope. Never. Not in the foreseeable future anyway.
> Everyone uses their own IDE, prompting style, and workflow.
In my experience with recent models this is still not a good idea: it quickly leads to messy code where neither AI nor human can do anything anymore. Consistency is key. (And abstractions/layers/isolation everywhere, as usual).
IDE - of course. But, at the very least, I would suggest using the same foundation model across the code base, .agent/ dirs with plenty of project documents, reusable prompts, etc.
--
P.S. Still not sure what does the 10AM rule bring, though...
I'm very much pro AI for coding there are clearly significant capabilities there but I'm still getting my head around how to best utilise it.
Posts like these make it sound like ruthlessly optimizing your workflow letting no possible efficiency go every single day is the only way to work now. This has always been possible and generally not a good idea to focus on exclusively. There's always been processes to optimise and automate and always a balance as to which to pursue.
Personally I am incorporating AI into my daily work but not getting too bogged down by it. I read about some of the latest ideas and techniques and choose carefully which I employ. Sometimes I'll try and AI workflow and then abandon it. I recently connected Claude up to draw.io with an MCP, it had some good capabilities but for the specific task I wanted it wasn't really getting it so doing it manually was the better choice to achieve what I wanted in good time.
The models themselves and coding harnesses are also evolving quickly complex workflows people may put together can quickly become pointless.
More haste, less speed as they say!
Genuinely seeking answers on the following - if you’re working that way, what are you “understanding” about what’s being produced? Are you monitoring for signal that points out gaps in your spec which you update; code base is updated, bugs are fixed and the show goes on? What insights can you bring to how the code base works in reality?
Not a sceptic, but thinking this stuff through ain’t easy!
Literally every single point in the article was good engineering practice way before AI. So it's either amnesia or simple ignorance.
In particular, "No coding before 10am" is worded a bit awkward, as it simply means "think before you write code", which... Does it need an article for saying it?
Also, if your spec is taking too long for the agent to execute, odds are high that it's ambiguous, unsound, unreviewed, underspecified, unmaintainable, or the model is just optimized to waste tokens so as to bill you maximally.
https://deep.liveblog365.com/en/index-en.html?post=195
The goal isn't to reject AI agents, but to ask: how do we build systems that last—not just ship fast? Would welcome thoughts from this community.