91–100 of 176 posts
Earlier quoted context omitted.
Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.
Disagree. Some learn, not all and decreasing numbers career to learn Also most juniors have no idea how to write tests, plan for data scale, know which IPC-RPC combo is best for prototyping vs production Etc… 90% of software is architecture and juniors don’t architect
This blog post shows how not to use AI. The author would have been unlikely to write such a uselessly redundant conclusion if they had to type it themselves. Edit: I like the post, but it didn't need to be padded with fluff.
We shouldn't be too quick to jump to "AI did it." People write redundant paragraphs and sentences in articles all the time because they're led to believe that every article needs a conclusion that sums up what's already been said. Ironically, including one in this article showed a lack of good judgment, which isn't confined to AIs.
Earlier quoted context omitted.
Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?" For me, not much! Others may differ. In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025). Also, there's a decently large subset of small startups where there's 1 technic…
The point is that no one should hire an intern or a junior because they think it will improve their team's productivity. You hire interns and juniors because there's a causal link between "I hired an intern and spent money training them" and "they joined my company full time and a year later are now productive, contributing members of the team". It's an investment in the future, not a productivity boost today.
There is no causal link between "I aggressively adopted Claude Code in 2025" and "Claude Code in 2026 functions as a full software engineer without babysitting". If I sit around and wait a year without adopting Claude Code that will have no measurable impact on Claude Code's 2026 performance, so why would I adopt it now if it's still at intern- or junior-level skill?
If we accept that Claude is a junior-level contribution then the rational move is to wait and watch for now and only adopt it in earnest if and when it uplevels.
When the work is equal to the knowledge and judgment of the painter, it is a bad sign; and when it surpasses the judgment, it is still worse, as is the case with those who wonder at having succeeded so well. But when the judgment surpasses the work, it is a perfectly good sign ; and the young painter who possesses that rare disposition, will, no doubt, arrive at great perfection. He will produce few works, but they will be such as to fix the admiration of every beholder.
Leonardo da Vinci, "A Treatise on Painting.", p. 225
https://archive.org/details/davincionpainting00leon/page/224...
This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…
What the heck, the code generation _is_ absolutely still a bottle-neck. I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have so…
If you don’t have the knowledge that begets the skills to do this work then you would never have known you were wasting your time or at least how to stop wasting time.
LLM fanboys don’t want to hear this but you can’t successfully use these tools without also having the skills.
Earlier quoted context omitted.
> Pop music is mostly not about music quality - hits are always passable - but about celebrity. Interesting and bold statement. How do you distinguish the two?
Whatever schlock Taylor Swift manufactures next will be a global hit. Doesn’t matter the quality
Earlier quoted context omitted.
I don’t think AI marks the end of software engineers, but it absolutely can grind out code for well specified, well scoped problem statements in quarter-minutes that would take a human an hour or so. To me, this makes my exploration workflow vastly different. Instead of stopping at the first thing that isn’t obviously broken, I can now explore nearby “what if it was slightly different in this way?” I think that gets…
> Instead of stopping at the first thing that isn’t obviously broken, I can now explore nearby “what if it was slightly different in this way?” What? Software engineering is about problem solving, not finding the first thing that works and called it a day. More often than not, you have too many solutions and the one that's implemented is the result of a list of decisions you've taken. > If it can make a dev team of 7…
I don't take credit for the value of being able to do with 7 what currently takes 8, but rather ascribe it to the ideas of Fred Brooks (and others).
Earlier quoted context omitted.
I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025). Also, there's a decently large subset of small startups where there's 1 technic…
> but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years The point is that no one should hire an intern or a junior because they think it will improve their team's productivity. You hire interns and juniors because there's a causal link between "I hired an intern and spent money training them" and "they joined my company full time and a year later are now produc…
> 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush
Having worked in environments with a large number of junior contractors... this is generally a recipe for a lot of effort with resulting output that neither works technically nor actually delivers features.
This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…
This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…
"these require deep understanding of the domain, the codebase, and good software engineering principles" Most of this AI can figure out eventually, except maybe the domain. But essentially software engineering will look a lot like product management in a few years.