If AI is a threat to software engineering, I wouldn't expect many software engineers to actively accelerate that trend. I personally don't view it as a threat, but some people (non engineers?) obviously do.
I'd be curious if any OpenAI engineers can share a rough estimate of their day to day composition of human generated code vs AI generated.
[0] https://www.lennysnewsletter.com/p/anthropics-cpo-heres-what...
for some products.
If it were 95% of anything useful, Anthropic would not still have >1000 employees, and the rest of the economy would be collapsing, and governments would be taking some kind of action.
Yet none of that appears to be happening. Why?
So let's take it on face value and say 95% is written by AI. When you free one bottleneck you expose the next. You still need developers to review it to make sure it's doing the right thing. You still need developers to be able to translate the business context into instructions that make the right product. You have to engage with the product. You need to architect the system - the context windows mean that the tasks can't just be handed off to AI.
So, The role of the programmer changes - you still need technical competence, but to serve the judgement calls of "what is right for the product?" Perhaps there's a world where developers and product management merges, but I think we will still need the people.
I think firing people does not come as a logical conclusion of 95% of code being written by Claude Code. There is a big difference between AI autonomously writing code and developers just finding it easier to prompt changes rather than typing them manually.
In one case, you have an automated software engineer, and may be able to reduce your headcount. In the other, developers may just be slightly more productive or even just enjoy writing code using AI more, but the coding is still very much driven by the developers themselves. I think right now Claude Code shows signs of (1) for simple cases, but mostly falls into the (2) bucket.
https://www.anthropic.com/candidate-ai-guidance
> During take-home assessments Complete these without Claude unless we indicate otherwise. We’d like to assess your unique skills and strengths. We'll be clear when AI is allowed (example: "You may use Claude for this coding challenge").
> During live interviews This is all you–no AI assistance unless we indicate otherwise. We’re curious to see how you think through problems in real time. If you require any accommodations for your interviews, please let your recruiter know early in the process.
He'd have to ask yet did not ask? A CPO of an AI company?
The other tactic is saying two unrelated things in a sentence and hoping you think it’s causal, not a fuck up and some marketing at the same time.
When you drill in you find out the real claims distill into something like "95% of the code, in some of the projects, was written by humans who sometimes use AI in their coding tasks."
If they don't produce data, show the study or other compelling examples, don't believe the claims; it's just marketing and marketing can never be trusted because marketing is inherently manipulative.
If we assume it isn't a lie, then given current AI capabilities we should assume that AI isn't being used in a maximally efficient way.
However, developer efficiency isn't the only metric a company like Anthropic would care about, after all they're trying to build the best coding assistant with Claude Code. So for them understanding the failure cases, and the prompting need to recover from those failures is likely more important than just lines of code their developers are producing per hour.
So my guess (assuming the claim is true) is that Anthropic are forcing their employees to use Claude Code to write as much code as possible to collect data on how to improve it.
I think the difference between situations where AI-driven development works and doesn't is going to be largely down to the quality of the engineers who are supervising and prompting to generate that code, and the degree to which they manually evaluate it before moving it forward. I think you'll find that good engineers who understand what they're telling an agent to do are still extremely valuable, and are unlikely to go anywhere in the short to mid term. AI tools are not yet at the point where they are reliable on their own, even for systems they helped build, and it's unclear whether they will be any time soon purely through model scaling (though it's possible).
I think you can see the realities of AI tooling in the fact that the major AI companies are hiring lots and lots of engineers, not just for AI-related positions, but for all sorts of general engineering positions. For example, here's a post for a backend engineer at OpenAI: https://openai.com/careers/backend-software-engineer-leverag... - and one from Anthropic: https://job-boards.greenhouse.io/anthropic/jobs/4561280008.
Note that neither of these require direct experience with using AI coding agents, just an interest in the topic! Contrast that with many companies who now demand engineers explain how they are using AI-driven workflows. When they are being serious about getting people to do the work that will make them money, rather than engaging in marketing hype, AI companies are honest: AI agents are tools, just like IDEs, version control systems, etc. It's up to the wise engineer to use them in a valuable way.
Is it possible they're just hiring these folks to try and make their models better to later replace those people? It's possible. But I'm not sure when in time, if ever, they'll reach the point where that was viable.
I am beginning to have more success with this in simpler parts of the code. Particularly if you already have a good example of how to do something and you need something very similar. I usually have to do a few tweaks but generally quite useful.
IJ does some truly stellar introspection to offer sane defaults in the current completion context, such as offering only variables of the correct type for parameters but I think of that as discipline and not AI. Plus, IJ never once made up an API that didn't exist
Software engineers have been automating away jobs for other people for nearly a century. It would be quite rich if the profession suddenly felt qualms about the process! (TBC I think automation is great and should always be pursued. Ofc there are real human concerns when change happens quickly but I am skeptical that smashing the looms is the best response)
And furthermore, what is the full causality chain that links the precise PR in provided example software to the employment termination decision? Lacking that, can you really assert the software 'automated' a dev out of the job?
There are two strong forces at play. Employees generally want to put in the least amount of effort possible and go home at 5. Employers want to save money and pay for fewer employees. AI creates a strong symbiosis here and both sides are focused on a short term win.
Really?
In my experience coding engineers are coders because they enjoy the challenge. they like building things, breaking things and rebuilding things.
Its the white-collar 9-5 office workers that churn out power-point and word documents that want to do as little as possible.
I love it, I've coded for 25 years and I don't need to write another line ever again, I just want to build cool things as fast as possible.
The right question is how much human code can a human push now vs prior to AI.
Everything we've done in coding has been assisted.
Prior to this current generation of web applications, we had the advent of concepts like Object Orientated Programming and prior to that even C was a massive move up from Assembly and punch cards.
AI has written a lot of code. AI has written very little high velocity production code by itself (ie. for people with no coding background).
In Ruby on Rails, the concept of fast coding has been around for over 20 years, look up this concept of Scaffolding: https://www.rubyguides.com/2020/03/rails-scaffolding/
So to answer your question,
1. AI has pushed a lot of code 2. AI has pushed almost no code without the oversight of human software engineers 3. Software engineers are pushing a magnitude more code and producing more functional utility and solving more bugs than ever before
I don't know what the future holds, but I do think that this is not a new trend to use software to help humans build faster, and I don't think software has the ability to fully replace humans (yet).
Citation needed
It’s not as clever as the author hoped.
I would say Ruby on Rails was a 10x on raw PHP in terms of feature specs per hour and AI is a 10x on Ruby on Rails (and its derivatives).
We're probably 100x the developer productivity on a per developer basis from the early days of Web 2.0 with PHP, just a personal anecdote though.
Only if you compare create a website in PHP 20 years ago vs using wordpress. But to create a project like wordpress from zero now is as difficult as it was 20 years ago.
This specific point is patently untrue. loveable/v0/etc excel at creating CMSes / UIs for content in hours.
Oh, please don't turn this site into StackOverflow 2.0.
OP's question is well defined. Any sentient being can understand what s/he meant.
AI is getting better at writing code. However writing code is just some fraction of the work of many software engineers. AI doesn't work independently, it needs to be guided, its work needs to be reviewed, tested etc. There are some domains where it does better and some domains where it doesn't. There's a range of "AI" work between auto-complete style work, assisting in understanding a code base, and writing code from some spec or doing other types work.
All in all I would say it's a decent improvement to productivity for many situations. It's really hard to say how much and it's also not a zero sum game, as productivity improves there's more work.
Something to keep in mind is that if you look at a modern software project likely most of the code executing is not code written by the developers of that project. There's a huge stack of open source bits executing for almost any new project.
Specifically in OpenAI you also need to consider what type of software they are likely writing. Some of it may be more or less "vanilla" code and other is likely very specialized/performance critical. The vanilla code like API wrappers or simple front end pieces is likely more amenable to be written by AI whereas the more cutting edge algorithmic/scheduling/optimization work is almost certainly not done by AI. At least yet.
As software organizations become larger there's a lot of overhead and waste. It is possible that AI can enable smaller teams and that has a multiplicative effect because it lets you reduce that waste/overhead. There are likely also software engineers who will become better/adapt to new workflows and some who will not. It's really hard to say where things are going but overall my sense is that this like many other innovations will lead to more software and more jobs and not the other way around. There are many moving pieces here, not just AI itself but geopolitics, macro-economics, etc. Where are those new jobs going to get created, what new types of software/technology are going to be created etc. etc. History seems to show us that we'll adapt/evolve and grow.
Ask "how much did you build then?" -> also 100%.
The compiler and I operate on different layers.
I actually use it from the web app not the cli. So far I've run over 100 codex sessions a great percentage of which I turned in to pull requests.
I kick off codex for 1 or more tasks and then review the code later. So they run in the background while I do other things. Occasionally I need to re-prompt if I don't like the results.
If I like the code I create a PR and test it locally. I would say 90% of my PR's are AI generated (with human in the loop).
Since using codex, I very rarely create hand written PR's.
crop_rotation•10h ago
This is a naive take. Throughout history things have been automated with the help of professions who were being automated away.
growbell_social•9h ago
I haven't seen too many industries be automated away first hand, and I'm sure there are historic examples. I wouldn't expect the lamp lighters to have been championing the rise of electric lamps. Maybe they did though because it meant they could work less hours.
madeofpalk•7h ago
est31•5h ago
One example is probably blacksmiths. Before, each larger village used to have one. Nowadays, this is not the case any more as people order replacement parts for whatever metal piece that broke in your car, house, etc. The metal molding happens in factories instead. But in order you still need to have people who know how to mold metals. The early folks for this profession were blacksmiths. Nowadays you would not call them any more. But it's definitely been "engineers with AI".
Same goes for industrialized food. The huge industrial bakeries still employ people who know how to bake bread, but they can do 1000x more than they could do if they had to knead the dough on their own, separate it, form little pieces of bread, order it nicely on a tray, etc.
Now it's a machine doing most pieces of work, but they still have folks who design new bread products, adjust machines, know what to change in the formula if one particular product from one particular supplier is not available in the quantities needed, etc. A lot of the skills needed aligns enough with the traditional job of a baker that these factories employ actual bakers.
As for software, whenever I use AI tools, I don't really feel that they help me save time much. But it's entirely possible that this is going to change in the future. They are only going to get better. And of course a lot of people say it's useful for them, so it already affects folks. Just because something is not useful to me doesn't mean it's not going to be useful to anybody.
iknowSFR•9h ago