I've seen people on social media bragging about how they're able to produce a mountain of code as if this was praiseworthy.
Hard to stay in flow and engaged.
Feels weirdly similar to being interrupted over slack.
Managing high performance dev/ops teams is it's own form of a state of flow. In fact for me, it's much more addicting than any other as the outcomes are usually many multiples of any IC role you could have. Even crazier when you have a "follow the sun" team involved so there the work just gets sequentially handed off and is always in constant motion.
I imagine AI coding is like this for a lot of folks.
At least in my case, flow is gone. It’s all context switching now.
Seriously, though, your question is one of those “how long is a piece of string” sort of questions. Just like any other software quality question, it depends on context, competence, goals, market dynamics, organizational culture, project timelines, team expertise, etc.
Do people pay their bills on time? Do people wear seatbelts? Do people brush their teeth for the full two recommended minutes? Depends, depends, depends.
In my own case 100% of my code is reviewed by humans (generally me), and that IMO is the only sensible option, and has been the standard since I started coding commercially 33 years ago. I don't use AI to generate code though, other than a few experiments, as I don't really need to write much code these days.
I wonder if the interface for this kind of thing might be better presented as a sort of JIRA ticket system. Define a dependency graph of work with the ability to break down any ticket into more tickets or change priority or relationships etc.
Though I think the micro manage part still doesn’t fit into that model. You’d need the code-level view and not just a ticket covering the tests that satisfy the spec and performance goals.
That's how I tend to describe AI to a lot of non-technical people (I actually generally say it's like having an really fresh intern who can read technical docs insanely fast but needs a lot of supervision).
At what point in time? Did anyone foresee coding being one of the best and soonest applications of this stuff?
It's why Codex, Claude Code, Gemini CLI etc. were developed at all - it was clear that if you wanted a concrete application of LLMs with clear productivity benefits, coding was low-hanging fruit, so all the AI vendors jumped on that and started hyping it.
I do agree that it was thought that these llm-agents would be extremely useful and that is why they were developed, and I happen to believe they in fact are extremely useful (without disagreeing that much of the stuff in the article definitely does happen.)
I just sort of resent the setup that it was supposed to be X but actually it failed, when not only is there only minor evidence that it failed, but it was only a brief period in time when it was supposed to be X.
During such phases of work, it's not unusual to put in some long hours in order to get up to speed.
With LLMs, it is possible to perpetually experience hundreds of thousands of lines of third party code, on about a weekly basis.
But this is not the same. The code is not known by anyone, anywhere else. It exists nowhere else, and so has no track record of deployment. No documentation, nothing. It's not something where you can concentrate on making a small modification, while trusting the rest of it to be working.
My 6 year old is doing my job.
The best I can hope for is that HN article that said the word "Context".
I know the magic words "Make me a single page html js web app"... or "Install Virtual Box with Fedora Cinnamon using CLI"....
I'm 8x more productive than I was in 2022... And I jokingly say "I'm probably not going to have a job in 1 or 2 years"...
We are going to create incredible value to humanity. 8x rate. I don't know what our hourly will be.
> We are going to create incredible value to humanity. 8x rate. I don't know what our hourly will be.
Do we have 8x more demand for software than current developers can currently supply? No, we don’t. Many developers will soon have a very bitter pill to swallow once they realize that developers are the beneficiaries of good market dynamics rather than some precious intellectual elite whose skills are monetizable in any other context.
Their hourly will be whatever DoorDash pays them to deliver pizza and egg rolls. Grad school isn’t any safer, and frankly, many of the soft, arrogant and maladroit people I’ve seen try to enter blue collar trades fail very quickly once they realize how hard the road is to get to those high salaries they always hear about.
1. llms allow devs to be more productive, so more free time is seen as opportunity for more work. ppl overshoot and just work more
2. generalized tooling makes devs seem more replaceable putting downward pressure on job security (ie work harder or we’ll get someone who will, oh and for less money)
3. llms allow for more “multitasking” (debatable) via many running background tasks, so more opportunities to “just finish one more thing”
There's this weird thing that happens with new tools where people seem to surrender their autonomy to them, e.g. "welp, I just get pings from [Slack|my phone|etc] all the time, nothing I can do than just be interrupted constantly." More recently, it's "this failed because Claude chose..." No, Claude didn't choose, the person who submitted the PR chose to accept it.
It's possible to use tools responsibly and effectively. It's also possible to encourage and mentor employees to do that. The idea that a dev has to be effectively on call because they're pushing AI slop is just wrong on so many levels.
It's not in the company's interest to stop employees from overworking. Having people overwork for the same pay under pressure is the desired outcome, actually.
I can relate to this, unfortunately these tools are becoming a very convenient way to offload any kind of responsibility when something goes wrong.
Code is literally always the last resort. Unless you're building solutions for other customer, most companies should attempt to minimise the amount of code they have. Because, and I repeat, it's a developers job to understand and review code. More code, more understanding needed, more reviews needed, more problems created.
My job is to generate more money, not indulge in code.