TL;DR
Anthropic recently published When AI Builds Itself, an essay explaining how AI is increasingly helping build the next generation of AI. Tod...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Hey Hemapriya. Hope you are well and great meeting with you on call yesterday!
Something is worth noting that it is pretty important today. I believe that AI is not going to replace developers because of the lack of funding of AI in general, and the consequences companies are slowly seeing as a result of developers using AI.
There has been some reports where companies are unable to build more data centers, mainly because of the cost to build them. Since AI is not really profitable, it's only a matter of time where companies are going to run out of money in which the bubble will "pop" from there. We are starting to see that with OpenAI where there are Ads on their ChatGPT. Keep in mind, they stated that ads are their "last resort" when it comes to profitability. This shows that they are in deep trouble when it comes to making profit on AI. If this continues, we will see that the bubble will pop.
The second thing is the consequences companies are facing. There are reports of companies seeing the impact that AI has on their company such as one company having their AI to wipe their whole database for some reason, etc. It gets to show that we needed more human workers to double check the work that we implemented using AI and knowing how to use it well.
One person in my Virtual Coffee mentions that Cyber Security is going to be ON DEMAND if the AI trend continues due to bugs that are easily fixable and bad practices developers are using because of AI. It is something worth noting.
When you mention this, this wraps up perfectly. Yes, AI helps us to do stuff faster, but it does not mean we throw away what we know. I treat my skills as a way for the worst case scenario where AI does not exist. If AI starts to get worse, at least I know my programming skills and knowing my StackOverFlows lol.
Hope this makes sense. This is my take on it. In any case, good report :D
Thanks, Francis! It was great talking with you yesterday. I really enjoyed our conversation 😃
I think you're right on all of those points. I kept this article focused on what the Anthropic essay was saying, but the economics behind AI, the cost of all this infrastructure, and whether it's actually sustainable are definitely part of the bigger conversation.
I also agree with what you said about fundamentals. That's actually one of the reasons I still spend so much time learning the basics. AI can definitely help us move faster, but it doesn't replace understanding why something is right or noticing when something feels off.
Thanks again for sharing your perspective. I always enjoy hearing your take on these kinds of topics.
Curious to see whether this ends up making engineering more creative… or just a lot more about supervising very fast-moving machines.
That's a question I've been thinking about too.
My guess is it will probably be a bit of both. The faster implementation becomes, the more time we might spend on architecture, problem-solving, and reviewing, but I also think supervising these systems well is going to become a skill in itself.
I'm curious to see how that balance evolves over the next few years.
I'm really glad the article came across that way because that was exactly what I was hoping to do. I also agree with what you said about software engineering. The more I thought about the essay, the more I felt it was really describing a shift in where engineers create value rather than a story about engineers becoming unnecessary.
Thanks again for taking the time to read it and leave such a thoughtful comment, Divyanshi. It really means a lot.
The execution vs judgment thing is what sticks after you read the Anthropic piece. The part I keep coming back to is what you said about realizing the skill you're trying to get better at isn't the one being automated. That reframe is harder than it sounds, especially early on when coding speed feels like the only thing that matters.
I write a series about AI breaking in production, and I keep ending up at the same place from a different angle — the people who win aren't the ones who can ship faster. They're the ones who can read the room, pick the right problem, and tell when the benchmark is lying. Your post puts words to why that keeps happening.
Thank you! I've actually read your series, so it was really nice to see your comment here.
The line about "the benchmark is lying" really captures something important. It's easy to focus on how much faster AI can help us ship, but someone still has to step back and ask whether we're solving the right problem and whether the results actually make sense.
It's interesting that we arrived at a similar conclusion from different directions. You came at it through testing and production failures, while I came at it through reading the Anthropic essay.
Thanks again for sharing your perspective!
That means a lot — knowing you'd read the series first and still found the comment worth replying to. The "benchmark is lying" line keeps showing up across all six stories because it's the same trap every time, just wearing different clothes. Glad it landed from your side too.
Looking forward to what you write next. Feels like there's a real conversation forming between these two angles — production stories and research analysis — and I think that's where the interesting stuff lives.
Thank you, that really means a lot.
I think you're right. They really do complement each other from different angles, and that's what makes these discussions so interesting.
I'm looking forward to the rest of your series as well. I'm sure we'll have more conversations like this as we both keep writing. 😄
The 80% number is the part I can't stop thinking about. I'm not sure how to interpret it.
"Authored by Claude" covers a lot of ground. Did the engineer describe the problem, review several iterations, and merge the final version? Did Claude generate a starting point that got heavily reshaped before it landed? I found myself wanting a little more detail on what "authored by Claude" actually includes because that changes how people read the number.
I appreciated that you didn't get stuck on the headline. The execution versus judgment discussion is the interesting part either way.
I actually had the same question while I was reading the essay. It gives some context around how Claude fits into their engineering workflow, but it doesn't really explain what "authored by Claude" means in practice. I think having more detail there would help people interpret the 80% figure.
That's probably one of the reasons I ended up focusing less on the 80% figure itself and more on the discussion around execution and judgment. For me, that was the part I kept thinking about.
Thanks for bringing that up, Shubhra!
It is difficult to answer. In my opinion "Authored By..." has the same meaning that i use in my posts, i am from Italy and don't know English so well to have a fluent debate or talking in this language. So i write my posts in Italian, translate with a translator (to maintain my personality), and ask to AI to refine and change some words or idioms for better understanding by community.
I think that this engineers and developers did the same things, automating what i do for posts by training LLMs in the specific context they works. so they have a strong generalist LLMs trained in their day to day work. Maybe in different contexts (not AI specific), the 80% became not true.
This is the same thing we do with instructions and system prompts, but a pre-trained system will be more and more efficient on specific argument.
If before starting a new project, we could train our LLM to think and act like us based on our skills and the data we have available, then perhaps it could even manage to be autonomous and develop that 80% of code, with the same bugs we would add 😁. Then we would masterfully add the 20% of missing bugs 😂😂.
Maybe i am wrong, or maybe not.
I hadn't thought about it from that angle, Marco.
I also think the context matters a lot. Anthropic's models are working inside an environment they know really well, with access to the company's tools, codebase, and workflows. That feels very different from asking a general-purpose model to build something from scratch.
And I had the same thought about your last point. If we ever end up training models on the way we work, they'll probably inherit some of our habits... including a few of our bugs 😄
Thanks for sharing your perspective!
AI is such a hot topic these days. 😀 The pace of AI development is incredibly fast, and it's hard to keep up with everything. However, using AI can make a huge difference in productivity, so all I can do is keep learning. And most importantly, AI is fun!
I completely agree 😀
It feels like there's something new to learn every week, which can be a little overwhelming at times. But I also think that's part of what makes this such an interesting time to be a developer. As long as we keep learning and experimenting, we'll be in a much better position to adapt to whatever comes next.
And yes, AI is definitely fun to play around with 😄
This article brilliantly reframed the AI conversation from 'will it replace developers?' to 'how is software engineering changing?' Your insight about execution vs judgment really resonated - AI can generate code, but human engineers remain critical for architecture, trade-offs, and ownership. The 8x productivity stat is mind-blowing! Thanks for this thoughtful analysis.
That change in perspective was exactly what I was hoping to capture. The numbers definitely caught my attention, but the discussion around how software engineering is changing ended up being much more interesting to me.
Thanks for reading and sharing your thoughts 😀
Spot on analysis, Hemapriya! The distinction between 'Execution' and 'Judgment' is the perfect reframe for this era. If Claude is writing 80% of production code and output volume is scaling 8x, we are about to face a massive, unaddressed architectural bottleneck on the open web.As millions of AI agents are deployed to interact with these rapidly generated codebases, they will inevitably choke on the 1.5 billion legacy websites designed purely for human UI. If implementation speed is no longer the bottleneck, data accessibility for machines becomes the new frontier.This forces us to shift our 'Judgment' from just auditing code to redefining network layers. How do we build an 'Agent Gateway' at the edge (like Cloudflare Workers paired with MCP and x402 micropayments) to serve these autonomous consumers without breaking legacy backend infrastructures? The 80% code automation trend isn't just changing how we program—it’s forcing us to re-engineer the bridge between the old human web and the new agentic web.
I hadn't thought about extending the discussion in that direction, but it's an interesting perspective. My article was mostly focused on how AI changes the role of software engineers, while you're looking at what those same trends could mean for the web itself.
It'll be interesting to see how that evolves as more AI agents become part of everyday software. Thanks for reading and sharing your thoughts 😀
Thanks for the thoughtful reply, Hemapriya!You're absolutely right—the shift in the engineer's role is immediate, but I believe the downstream impact on web infrastructure will catch many by surprise. When AI is writing 80% of the code, we’ll hit a wall where machines are trying to consume websites designed strictly for human eyes.
I’m actually building in public to solve this exact bottleneck (creating an "Agent Gateway" layer for legacy webs to become machine-readable via MCP).
Looking forward to your next articles! Let's see how fast this agentic wave reshapes the internet.
That's really interesting. I'll definitely be keeping an eye on how your project develops.
I hadn't really thought much about the infrastructure side until this discussion, so it's been interesting to see that perspective. It'll be fascinating to see how all of this evolves over the next few years.
Thanks again for the conversation, and all the best with what you're building!
Thank you, Hemapriya! I really appreciate the encouragement and the great conversation.
Your article sparked exactly the kind of debate the community needs right now. I’ll keep building in public and sharing updates as the Agentic Web unfolds.
Wishing you all the best with your upcoming pieces, and let's stay connected!
And they just casually told us about J-Space. Today it is this, yesterday it was about that, tomorrow it shall be about # ? I mean shall there be an end? As they say, change is constant. DO NOT be anxious. Remember AGI?
Haha, you're right, Clement 😄
Every few months there's a new headline that's supposed to change everything. I guess the only constant is that there'll always be another one waiting around the corner.
Very true, remember the Bored APE NFT? Hehehehe
I am currently reading these books, Maybe they can help, a bit
goodreads.com/en/book/show/2393626...
goodreads.com/en/book/show/5318209...
goodreads.com/en/book/show/5107538...
And better Yet the OLD but GOLD, I had read a while back; call these V1, while the above as V2
goodreads.com/en/book/show/6143904...
goodreads.com/book/show/5129.Brave...
😂 Haha, the Bored Ape NFT era feels like a lifetime ago now.
Thanks for sharing these, Clement. I haven't read them yet, but I'll definitely take a look. I always appreciate good book recommendations.
Such a great breakdown, Hemapriya! It’s a massive relief to read a take on that Anthropic essay that doesn't feel like pure doom-scrolling fuel.
That "80% of code written by Claude" headline sounds terrifying until you actually look at what it means. Your point about execution vs. judgment is spot on. Merging 8x more code sounds cool on paper, but as someone who’s been in the fullstack trenches for a while... that just sounds like 8x more technical debt to debug at 3 AM. AI can spit out code at warp speed, but it’s not the one waking up when the production server starts crying. 😆
You're exactly right about fundamentals, too. Our jobs are shifting from "code writers" to glorified system judges. Honestly, it takes way more brainpower to audit 500 lines of AI-generated state management logic and spot the hidden memory leaks than it does to just build the thing from scratch.
Since you mentioned you're early in your career—seriously, don't sweat the hype. The fact that you’re already looking past the syntax and focusing on system architecture means you’re tracking exactly where the industry is going.
Awesome write-up, definitely saving this one! 👍🏻
Thank you so much, Amodit!
I had to laugh at the "production server starts crying" line 😄 But I think you're right. Generating code faster doesn't automatically make maintaining it easier, and that's something I kept thinking about while reading the essay.
And thanks for saying that. Being early in my career, it's easy to get caught up in all the headlines. Reading the original essay helped me focus a lot more on the bigger picture instead of just the code generation side of things.
Really appreciate you taking the time to leave such a thoughtful comment!
Great post
Thank you so much 😀
Valid point: AI building AI can accelerate software, not just accelerate humans. But as tools bootstrap themselves, we need guardrails, traceable provenance, and verifiable safety nets. Otherwise we risk opaque self-improvement with no accountability. And yes, someone still has to debug the AI’s 'self-jokes' in the logs.
I was thinking about some of those same questions while I was reading the essay. Once AI starts becoming part of the development process itself, conversations around traceability, verification, and accountability become just as important as capability.
And yes, I have a feeling we'll all end up debugging a few of those AI "self-jokes" 😄
Your central frame is doing the heavy lifting: the thing being automated is not the skill you are trying to become better at. That sentence is correct, and it is the part the loudest takes keep skipping.
One wrinkle I think worth naming. The judgment side is not just slow to automate. It is a predictor trained on a corpus of guesses that ate consequences. If the model writes the hundred options, your corpus did not grow. You did not falsify a guess. You did not pay the cost that updates a predictor. The output looked like work. The training did not happen.
That is why "the skill" is still yours to build, but only if you keep paying into the loop. The same essay that says judgment stays premium also describes the exact workflow that makes it easier to skip the cost of training it.
I wrote a longer piece on this earlier today, if useful as a side angle: jugeni.substack.com/p/taste-is-a-p...
Thanks, Mike. I think that's a really interesting angle.
I was mostly focused on where engineers continue to create value, while you went one step further and talked about how that judgment actually gets built in the first place. That's a good reminder because it's easy to mistake AI-generated output for our own learning.
I'll definitely give your article a read. Thanks for sharing it.
The uncomfortable part of AI building AI is that review has to move up a level. You are no longer only checking code; you are checking the loop that produced the code, the evals it trusted, and the incentives it optimized for.
That's an interesting way to look at it, and I think it fits well with what I took away from the essay.
If implementation becomes easier, then a bigger part of the job shifts toward asking whether the process, assumptions, and outputs actually make sense instead of only reviewing the final code.
I hadn't thought about it from the angle of reviewing the loop itself. Thanks for sharing that.
This was one of the most balanced takes I’ve read on Anthropic’s “When AI Builds Itself.” What stood out to me is that the real shift isn’t simply AI writing more code—it’s AI becoming part of the development loop for future AI systems. That changes software engineering from primarily implementation work to a combination of architecture, verification, governance, and risk management. The article also highlights an important point that often gets missed: faster iteration cycles increase the need for stronger human oversight, not less.
I'm glad that came across because that was exactly what I was hoping to highlight. The productivity numbers are impressive, but I found the shift in the engineer's role much more interesting. Like you said, faster iteration doesn't remove the need for oversight. If anything, it makes it even more important.
Thanks for taking the time to read the article and leave such a thoughtful comment.
Great perspective. AI is accelerating software development, but critical thinking, system design, and sound engineering judgment remain the skills that create the most value. Reading original sources instead of headlines is always worthwhile.
I agree. Reading the original essay completely changed how I thought about the topic. It reminded me how easy it is for the discussion around something to become very different from the source itself.
Thanks for reading and sharing your thoughts 😀
I wrote this from the perspective of someone who's still early in their career, so I would really value hearing from people with different levels of experience.
Has AI actually changed the way your team builds software, or is the online conversation running ahead of reality? What parts of your job have changed the most, and what hasn't?
Looking forward to hearing different perspectives.
Hey Hemapriya. Good work again and thanks for the comment you left on my comment.
In my opinion, it would be nice to have some pictures on future posts. Will make it look nice :)
I was actually thinking the same thing while I was writing this. I used to include GIFs in some of my earlier articles, and I think they definitely help make longer posts easier to read.
I'll try to bring the GIFs back, and I'll also try to add some images from my next article onward. Thanks for the suggestion!
Congratulations on your engineering attitude and intellectual desire to understand better. I believe that every engineering activity has, as an essential preamble, the ability to understand how a system is actually an organism consisting of a dense network of subsystems. Only when the engineer is clear about how these subsystems should work and cooperate can the first line of code be started. Thank you for your lucid and passionate analysis.
Thank you so much for your kind words. I agree with what you said. The more I learn, the more I realize that writing code is only one part of engineering. Understanding how the different pieces of a system fit together and why they work the way they do feels just as important.
I appreciate you taking the time to read the article and leave such a thoughtful comment.
I am the one who thanks you, for your patience in reading the Anthropic paper and making relevant inferences for every degree of experience, because regardless of our experience, our field, already very rapid in evolutions, today as never before the speed of change concerns more areas of reflection. I wish you all the best.
The shift that piece triggers for a lot of people is realizing the bottleneck was never typing. When AI builds itself, the scarce skill moves to specifying intent and verifying output, the parts that were always the actual engineering. The uncomfortable follow-on is that the traditional way people built that judgment, doing the rote work by hand, is exactly what's getting automated. Worth sitting with how the next generation reaches that judgment if they skip the grind that used to teach it. The role doesn't disappear, but the on-ramp to it gets steeper.
That's a really good point, Theo.
I hadn't thought about it from that angle while I was writing the article, but I think you're right that it's an important question. If the work that used to teach us those lessons becomes easier to skip, we'll probably have to be much more intentional about how we build that judgment.
As someone who's still early in my career, that's definitely something I'm thinking about more now.
Thanks for sharing your perspective.
The line that stuck with me is judgment not being automated even as execution is. That 51 to 64% jump in choosing the better next step is real progress, and it still leaves roughly a third of the time where something has to catch that the choice was wrong. Merging 8x more code only helps if the reviewing judgment scales with it, and that's the skill I'm trying to grow rather than race the model on typing speed.
Thanks, Kartik. I really like that way of looking at it.
That was one of the biggest things I took away from the essay too. The progress is impressive, but that remaining gap made me think more about the kind of skills I want to keep building. Like you said, I'd rather get better at making good decisions than try to keep up with AI on implementation speed.
Thanks for sharing your perspective!
You landed on the exact distinction most of these threads miss: execution got cheap, judgment didn't. From the CTO seat that's the whole game now. On my team AI didn't replace anyone — it made the seniors dramatically more productive, because the bottleneck moved from how fast we write code to how well we review it and set the rails around it. The model that stuck for me: it's like having an army of juniors who almost never make a syntax mistake but have zero taste. They'll build exactly what you ask, including the wrong thing, very fast. So the skill that compounds isn't prompting — it's knowing what's worth building and smelling when an answer is confidently wrong. That's actually a great place to be early in your career, because taste is built by shipping and reviewing, not by years served. Encouraging read — which of your three ways do you think is most likely?
Thanks so much, Arun. I really appreciate you taking the time to share your perspective.
I really liked your "army of juniors" analogy. It captures the idea well. They can move incredibly fast, but someone still has to decide whether they're building the right thing.
As for the three scenarios, if I had to pick one today, I'd probably lean toward the middle one. It feels like the most natural extension of what we're already seeing, where AI becomes a much bigger part of the workflow while people spend more time on judgment, architecture, and review. That said, things have been moving so quickly that I wouldn't be surprised if I end up revisiting that opinion a few years from now.
Thanks again for such a thoughtful comment!
the 80% stat is wild but what really got me thinking is the feedback loop implication — if AI writes most of the code, then code review quality becomes the actual bottleneck rather than writing speed. feels like we're shifting from being builders to being editors
I was thinking about that too.
The faster AI gets at implementation, the more important review becomes. I do think it's a little broader than just being editors, though. We're also spending more time deciding what to build and whether the result actually solves the right problem.
That ended up being the biggest takeaway for me from the essay.
Thanks for sharing your perspective!
That's a great point Hemapriya — the bottleneck shifts from "how to build it" to "should we build this at all?" AI makes execution fast, but judgment stays human. Appreciate the conversation, really made me think about this differently!
Thank you! I'm really glad to hear that.
I've really enjoyed this conversation too. The essay gave me a lot to think about, and it's been interesting seeing how different people have interpreted it.
Thanks again for sharing your perspective!
Amazing article Hemapriya, I wouldn't say this completely suppressed my anxiety as someone new to this field, but it gave me a direction at least. The skill I was actually trying to get better at is writing codes, syntax and algorithms, but now it looks like those skills are getting more automated as time passes. I'm now more focused on learning the basics, how systems think and react and the infrastructure rather than just building and shipping products. How would you advice someone looking to take this direction should start?
I'm still early in my career too, so I don't feel like I'm in a position to give definitive advice. But if there's one thing reading the essay changed for me, it's where I'm putting my attention.
I'm still learning to write good code, but I'm also spending more time understanding the fundamentals behind it. Things like operating systems, networking, databases, distributed systems, and system design. I'm trying to understand why systems work the way they do, not just how to make them work.
I don't think building projects becomes less important either. If anything, it's a chance to apply those fundamentals and see where the trade-offs are.
So I guess my advice would be to keep building, but don't skip the foundations. I think those skills will only become more valuable over time.
Thanks for asking such a thoughtful question, and I wish you all the best on your journey 😀
I guess this is a better way to go about it. Thank you and goodluck in your journey too
Great read. I'm currently exploring AI automation, and this really resonated with me. AI can make implementation faster, but judgment and problem-solving still seem to be the skills that matter most. Thanks for sharing such a balanced perspective.
Reading the essay definitely changed the way I was thinking about it. AI is making implementation much faster, but it also made me realize how important understanding the problem and making good decisions really are.
All the best with your AI automation journey, and thanks for sharing your thoughts 😀
This is exactly what the conversation around AI needs. As someone also navigating this space, the constant stream of doom-scrolling headlines can definitely induce a lot of quiet anxiety. Your point about computer science fundamentals—learning how to reason about systems rather than just memorizing syntax—is spot on. Thanks for taking the time to read the source material and share such a grounded perspective!
I think a lot of us, especially those still early in our careers, have felt that quiet anxiety at some point. Reading the original essay didn't answer every question I had, but it definitely gave me a much better way to think about what skills I want to keep building.
Thanks for taking the time to read the article and share your thoughts, Srashti 😀
Great read. I had a similar takeaway. As I'm building MCP Skills and agent workflows, it made me wonder where humans fit as AI gets better at building AI. Even if we reach recursive self-improvement, it doesn't automatically solve humanity's biggest challenges. Climate change, for example, isn't just an engineering problem—it's also a coordination problem involving 'human layers' such as politics, economics, regulations, and international cooperation. AI can accelerate solutions, but humans still have to decide and act.
I hadn't thought about it from that perspective, but I think you're right. Even if AI keeps improving technically, there are still a lot of problems that depend on people working together, not just better technology.
Thanks for sharing your thoughts. It definitely gave me something else to think about.
I've come to similar conclusions when using claude code to build everything the last 6 months. I've moved to a higher level overview, review, imagine, architect and directing. It's quite pleasing in a lot of ways - I only miss coding sometimes. Importantly because of the fast iterations and not being distracted by code implementation I have found I'm learning much more about software architecture and actually solving problems. I see that I can choose the right stacks, design patterns and devops much faster now depending on the project needs. This was something you only do a few times a year, I'm doing weekly. Being able to build a throwaway app in a day, test a few different ways to architect, deploy then go intot he actual impelmentation has really changed the codebase and devops maintainability.
How I see it is Developers are now at a much highler level signal. You need to change the signals you receive to allow you to become even better. For example, when I first started with agents I used to watch them do tool calls, analyze every bit of code change at every iteration, etc. This changed to building our parallel smaller tasks from larger features, letting the agent do their work and change scenery, do more planning, other reviews, get back to it when the agents are done. You are processing a lot more highler level information - and a lot of context switch if you over parallelize, which can be tiring but it's not as bad as being stuck on npm depencency mismatches or broken tooling for hours which truly went nowhere.
We should never have thought we had static labels as job requirements in the first place. I think that was the big change.
Thanks for sharing this, Gabe.
I hadn't thought about it from that angle, but what you said about being able to try different architectures in a day makes a lot of sense. That's a very different way of learning than spending all your time getting one implementation working.
I also really liked your last point. We probably do get attached to what we think a developer's job is supposed to look like, when in reality it's always been changing.
Really appreciate you sharing your experience. It's interesting to hear from someone who's been working this way for a while.
After reading this article and reflecting on the current state of the industry, I’m increasingly convinced that the speed of AI’s evolution far exceeds everyone’s earlier predictions. Many people are still arguing that AI is merely an auxiliary tool, yet widespread workforce reductions are already a tangible reality—major tech firms are cutting their engineering headcounts by leveraging AI.
If we extrapolate from the ongoing self-iteration trend of models like Claude, the software development industry will inevitably face a precipitous drop in staffing levels in the future. Companies will no longer need large teams of engineers focused on hands-on coding work; only a tiny cohort of core developers will be retained. These specialists will possess deep knowledge of system architecture and business logic, tasked with reviewing and fixing vulnerabilities introduced by AI. The vast majority of roles involving repetitive development, debugging, and API implementation will be fully taken over by AI. This is no alarmist rhetoric, but an industry trend already unfolding before our eyes.
Thanks for sharing your perspective.
I can definitely understand why you see it that way. The pace of progress has surprised a lot of people, including me, and it's one of the reasons I wanted to read the original essay instead of relying on headlines.
I still think there's a lot of uncertainty around how this plays out over the next few years. That's why I found the discussion around execution versus judgment more interesting than trying to predict exactly what the job market will look like. It'll be interesting to see which parts of today's work change the most.
Thanks again for taking the time to share your thoughts.
Really enjoyed this. The part that landed for me most was your execution-vs-judgment framing — that is exactly where a lot of the online discourse gets distorted. As someone building with AI every day, I also keep seeing that raw implementation speed is compounding fast, but deciding what is worth building and what result is actually trustworthy is still the leverage point. I also liked that you read the original Anthropic essay instead of reacting to the headline stat alone. That habit matters a lot right now.
Reading the original essay honestly changed the way I thought about the whole discussion. Before that, I had mostly seen the 80% number in headlines without much context. Taking the time to read the source made me realize the more interesting part wasn't the statistic itself, but what it said about how the work is changing.
It's also interesting to hear that you're seeing something similar from actually building with AI every day. Thanks for sharing your perspective, Vic 😀
the 'execution vs judgment' framing is the one that finally made the 8x number feel less alarming.
what i've seen in practice: the judgment calls that actually matter aren't 'should i write this function' — they're 'is this the right abstraction' and 'does this output make an upstream assumption that will break in 6 months.' those are harder to delegate because they require context the model doesn't have.
the 8x code output number probably understates the judgment load on humans in the loop. more code ships, more decisions per deploy. curious whether you see that pattern or whether tooling is catching up with the review burden?
That's a really interesting way of looking at it.
I hadn't thought about it as "more code ships, more decisions per deploy," but that makes a lot of sense. My guess is that tooling will keep improving, but I also think the review burden grows with it. Even if AI helps with reviews, someone still has to decide whether the design makes sense, whether the assumptions hold, and whether the solution actually fits the problem.
I'm still early in my career, so I don't have enough real-world experience to know exactly how that balance will play out. It'll be interesting to see how teams adapt as these tools become part of everyday development.
Thanks for sharing your perspective and for the question!
Great article - I totally agree that Software Development was never just about coding (though I think that some devs do believe that - to the exclusion of design, data preparation, documentation, test creation, testing and many other facets of the entire process). AI is a great tool that does not take away from the broader human role. I wrote a brief linkedin post about this in 2025 and had a massive pile-on from disgusted/angry devs. Your article is much more well thought out than my brief post.
I think you're right. Software engineering has always involved much more than writing code, but with so much of the conversation focused on code generation, it's easy to forget everything else that goes into building good software.
I'm sorry to hear your post got that reaction. AI is one of those topics where discussions can get heated very quickly. I was hoping this article would encourage a more balanced conversation, so I'm really glad it came across that way.
Thanks for taking the time to read it and share your experience, Doug!
AI is clearly speeding up code generation, but the real value still lies in judgment, deciding what to build, what makes sense, and what actually holds up.
I agree. That was the biggest thing I took away from the essay too.
The progress in code generation is impressive, but it made me realize that deciding what to build and evaluating the result become even more important as implementation gets faster.
Thanks for reading and sharing your thoughts!
This is such a thought-provoking read! I never considered the funding angle before. Thanks for sharing this perspective.
The funding side is definitely an interesting part of the broader conversation, even though I kept this article focused on the Anthropic essay itself. It feels like there are a lot of different pieces to this story, and we're only just starting to see how they fit together.
Thanks for reading 😀
Totally agree! It does feel like we are still connecting the dots between the technical implications and the business model side. The essay raised more questions than it answered, but I think that is exactly what makes it worth discussing. Looking forward to reading more of your takes on this topic!
I completely agree. That was one of the things I liked most about the essay. It didn't try to pretend it had all the answers, and I think that made it a much more interesting read.
And thank you! I'm definitely planning to write more as I keep reading and learning 😀
Human opportunities are trapped in the illusion of AI.
that's such an useful stuff, this is what actually happening
Thank you! I'm really glad you found it useful 😀
That was exactly why I wanted to write this. There's a lot of discussion around AI right now, and I wanted to understand what was actually happening by reading the original essay instead of just the headlines.
I've found AI is best when it handles the first draft, not the final call. The more context you give it, the more your job becomes reviewing decisions instead of typing code.
I can relate to that. The more context I've given AI, the more I've found myself spending time reviewing and refining instead of writing everything from scratch.
It definitely feels like a different way of working than it did even a year ago. Thanks for sharing your experience!
its a suprise
Impressive.
Thank you so much 😀
Thank you!
Coding hasn’t been the main part of software engineering for decades. So when they repeat that as if it were some new reassurance, it makes me wonder who this message is actually meant for.
That's a fair point, David.
I think this article is probably aimed more at people like me who are still early in their careers. When so much of the discussion online is about AI writing code, it's easy to start thinking that coding is the whole job. Reading the essay reminded me that software engineering has always been much broader than that.
That's really what I was trying to get across.
Build your AI SaaS this weekend with AI RAG
checkout - Fastrag
Check mfenx