> Yeah, there's the nice thoughts like "we wouldn't know how to maintain our app" -- but Claude would do a decent job in a single dev's hands, or "AI will potentially change the application unintentionally and introduce bugs" -- but proper observability, testing, and further prompting could fix those things in minutes to hours.
I was thinking about that the other day when I was automating a workflow: I hooked up Jira to Claude so that bug reports would automatically get a pull request. Opus 4.7 is pretty good at it. And compared to dev costs it's still quite cheap.
It's nice to not be distracted by simple bugs, but aren't I killing my own job?
Ah I should have put that on my list, I've done a lot of standup paddle boarding and kayaking on the harbour, and I can highly recommend it. Places like Balmoral are ideal for it because it's very calm and there's a lot to see and do
On small PRs (small features / changes ~hundreds to thousands of lines), I'd say around 500,000 total tokens.
On large PRs (new feature sets for apps ~10,000-30,000 lines), around 2-3 million total tokens.
By the way, I should have mentioned in my original post, adamsreview counts tokens used by sub-agents across the stages, and tells you at the end of each stage the total used so far.
> This is a great insight. For software engineers coding is the way to fully grasp the business context.
> By programming, they learn how the system fits together, where the limits are, and what is possible. From there they can discover new possibilities, but also assess whether new ideas are feasible.
Maybe I have a different understanding of "business context", but I would argue the opposite. AI tools allow me to spend much more time on the business impact of features, think of edge cases, talk with stakeholders, talk with the project/product owners. Often there are features that stakeholders dismiss that seemed complex and difficult in the past, but are much easier now with faster coding.
Code was almost never the limiting factor before. It's the business that is the limit.
It’s perplexing; like the majority of people who insist using AI coding assistance is guaranteed going to rob you of application understanding and business context aren’t considering that not every prompt has to be an instruction to write code. You can, like, ask the agent questions. “What auth stack is in use? Where does the event bus live? Does the project follow SoC or are we dealing with pasta here? Can you trace these call chains and let me know where they’re initiated?”
If anything, I know more about the code I work on than ever before, and at a fraction of the effort, lol.
The project managers and CEOs who are vibe-coding apps on the weekend don't know what an "auth stack" is, much less that they should consider which auth stack is in use. Then when it breaks, they hand their vibe-coded black box to their engineers and say "fix this, no mistakes"
I think that for the average developer this might be true. I think that for excellent developers, they spend a lot of time thinking about the edge cases and ensuring that the system/code is supportable. i.e. it explains what the problems are so that issue can be resolved quickly; the code is written in a style that provides protection from other parts of the system failing; and so on. This isn't done on average code and I don't see AI doing this at all.
Can complain to your local MEP about that. They updated the passenger rights regulation recently, but still kept this/
Regulation (EU) 2021/782
> Railway undertakings may introduce a minimum threshold under which payments for compensation will not be paid. This threshold shall not exceed EUR 4 per ticket.
Sadly the MEPs cared more about railway companies than passengers.
reply