That's why I'm not worried. There is already SO MUCH more demand for code than we're able to keep up with. Show me a company that doesn't have a backlog a mile long where most of the internal conversations are about how to prioritize what to build next.

I think LLM assistance makes programmers significantly more productive, which makes us MORE valuable because we can deliver more business value in the same amount of time.

Companies that would never have considered building custom software because they'd need a team of 6 working for 12 months may now hire developers if they only need 2 working for 3 months to get something useful.

I worry about junior developers. It will be a while before vocational programming courses retool to teach this new way of writing code, and these are going to be testing times for so many of them. If you ask me why this will take time, my argument is that effectively wielding an LLM for coding requires broad knowledge. For example, if you're writing web apps, you need to be able to spot say security issues. And various other best practices, depending on what you're making.

It's a difficult problem to solve, requiring new sets of books, courses etc.

This isn't to say you are wrong but just to put some perspective on how things are changing. Maybe most new programmers will be hired into AI roles or data science.

I appreciate anyone that can utilise ai well but there’s just not enough core ai model development jobs for every new grad.

What are those “day to day business needs” that you think people are going to do without AI?

In my view, this is like 1981. If you are saying, we will still need non-computer people for day-to-day business needs, you are wrong. Even the guy in the warehouse and the receptionist at the front are using computers. So is the CEO. That does not mean that everybody can build one, but just think of the number of jobs in a modern company that require decent Excel skills. It is not just the one in finance. We probably don’t know what the “Excel” of AI is just yet but we are all going to need to be great at it, regardless of who is building the next generation of tools.

I would assume any other CS course teaches/is going to be teaching how to use AI to be an effective software developer.

I didn’t get a smart phone until the 2010s. Stupid I know but it was seen as a badge of honour in some circles ‘bah I don’t even use a smart phone’ we’d say as the young crowd went about their lives never getting lost without a map and generally having an easier time of it since they didn’t have that mental block.

Ai is going to be similar no doubt. I’m already seeing ‘bah I don’t use ai coding assistants’ type of posts, wearing it as a badge of honour. ‘Ok you’re making things harder for yourself’ should be the reply but we’ll no doubt have people wearing it as a badge of honour for some time yet.

The mantra has always been that the best way to learn to code is to read other people’s code. Now you can have “other people” write you code for whatever you want. You can study it and see how it works. You can explore different ways of accomplishing the same tasks. You can look at the similar implementations in different languages. And you may be able to see the reasoning and research for it all. You are never going to get that kind of access to senior devs. Most people would never work up the courage to ask. Plus, you are going to become wicked good at using the AI and automation including being deeply in touch with its strengths and weaknesses. Honestly, I am not sure how older, already working devs are going to keep up with those that enter the field 3 years from now.

Now, the first response some folks may have is, how can you trust that the AI is good at security? Well, in this example, it only needs to be better than the junior developers at security to provide them with benefits/learning opportunities. We need to remember that the junior developers of today can also just as easily write insecure code.

Instead of this, have you considered asking Deep Seek to explain it to you?

For mankind, the really big problems aren't going away any time soon.

But -- and it's a big but -- many of us aren't working on those problems. I'm ready to agree most of what I've done for decades in my engineering job(s) is largely inconsequential. I don't delude myself into thinking I'm changing the world. I know I'm not!

What I'm doing is working on something interesting (not always) while earning a nice paycheck and supporting my family and my hobbies. If this goes away, I'll struggle. Should the world care? Likely not. But I care. And I'm unlikely to start working on solving societal problems as a job, it's too much of a burden to bear.

And here is the problem: AI needs to be trained on something. Use of AI reduces the use of online forums, some of them are actively blocking access, like reddit. So, for AI to stay relevant it has to generate the knowledge by itself. Like having full control of a computer, taking queries from human supervisor, and really trying to solve. Having this sort of AI actors in online forum will benefit everyone.

Everybody is a Manager now?

The ones who are self-starters will do fine - they'll figure out how to accelerate their way up the learning curve using these new tools.

People who prefer classroom-learning / guided education are going to be at a disadvantage for a few years while the education space retools for this new world.

I’d love to watch, e.g. you Simon, using these tools. I assume there are so many little tricks you figured out over time that together make a big difference. Things that come to mind:

- how to quickly validate the output?

- what tooling to use for iterating back and forth with the LLM? (just a chat?)

- how to steer the LLM towards a certain kind of solutions?

- what is the right context to provide to the LLM? How do it technically?

Really, what seems on the horizon is a cliff of techno risks that have nothing to do with "AI will take over the world" and more "AI will be so integral to functional humanity that actual risks become so diffuse that no one can stop it."

So it's more a conceptual belief: Will AI actually make driving cares safer or will the fatalities of AI just be so randomly stochastic that it's more acceptable.

I would argue that we already accept relatively random car fatalities at a huge scale and simply engage in post-hoc rationalization of the why and how of individual accidents that affect us personally. If we can drastically reduce the rate of accidents, the remaining accidents will be post-hoc rationalized the same way we always have rationalized accidents.

Currently, car crashes are blamed on the individuals involved.

I reckon we'll see a lot of new religious thinking about this stuff

This is about the functional society where people fundamentally have recourse to "blame" via legal means one another for things.

Having fallbacks, eg, pilots in the cockpit is not a long term strategy for AI pilots flying planes because they functionally will never be sufficiently trained for actual scenarios.

I don't agree. LLMs work as template engines on steroids. The role of a developer now includes more code reviewing than code typing. You need the exact same core curriculum to be able to parse code, regardless if you're the one writing it, it's a PR, or it's outputted by a chatbot.

> For example, if you're writing web apps, you need to be able to spot say security issues. And various other best practices, depending on what you're making.

You're either overthinking it or overselling it. LLMs generate code, but that's just the starting point. The bulk of developer's work is modifying your code to either fix an issue or implement a feature. You need a developer to guide the approach.

It isn't. Anyone who does software development for a living can explain to you what exactly is the day-to-day work of a software developer. It ain't writing code, and you spend far more time reading code than writing it. This is a known fact for decades.

> If the IDE checks types and feeds errors back to the LLM,(...)

Irrelevant. Anyone who does software development for a living can tell you that code review is way more than spotting bugs. In fact, some companies even have triggers to only trigger PR reviews if all automated tests pass.

Extremely well paid human coders, capable of fixing the mistakes of the years preceding them...

I'm by no means an expert, but I feel like you still need someone who understands underlying principles and best practices to create something of value.

Thinking it out even further, programming languages will likely go away altogether as ultimately they're just human interfaces to machine language.

As we know them, certainly.

I haven't seen discussions about this (links welcome!), but I find it fascinating.

What would a PL look like, if it was not designed to be written by humans, but instead be some kind of intermediate format generated by an AI for humans to review?

It would need to be a kind of formal specification. There would be multiple levels of abstraction -- stakeholders and product management would have a high level lens, then you'd need technologists to verify the correctness of details. Parts could still be abstracted away like we do with libraries today.

It would be way too verbose as a development language, but clear and accessible enough that all of our arcane syntax knowledge would be obsolete.

This intermediate spec would be a living document, interactive and sensitive to modifications and aware of how they'd impact other parts of the spec.

When the modifications are settled, the spec would be reingested and the AI would produce "code", or more likely be compiled directly to executable blobs.

...

In the end, I still think this ends up with really smart "developers" who don't need to know a lick of code to produce a full product. PLs will be seen as the cute anachronisms of an immature industry. Future generations will laugh at the idea that anybody ever cared about tabs-v-spaces (fair enough!).

Take for example neuralink. If you consider that interface 10 years, or further 1000 years out in the future, it's likely we will have a direct, thought-based human computer interface. Which is interesting when thinking of this for sending information to the computer, but even more so (if equally alarming) for information flowing from computer to human. Whereas today, we read text on web pages, or listen to audio books, in that future, we may instead receive felt experiences / knowledge / wisdom.

Have you had a chance to read 'Metaman: The Merging of Humans and Machines into a Global Superorganism' from 1993?

This is a problem that the Computer Science departments of the world have been solving. I think that the "good" departments already go for the "broad knowledge" of theory, systems with a balance between the trendy and timeless.

Why?

Are they not already?

> It's a difficult problem to solve, requiring new sets of books, courses etc.

I think new tooling built around LLMs that fits into our current software development lifecycle is going to make a big difference. I am experiencing firsthand how much more productive I am with LLM, and I think that in the future, we will start using "Can you review my conversation?" in the same way we use "Can you review my code?"

Where I believe LLMs are a real game changer is they make it a lot easier for us to consume information. For example, I am currently working on adding a Drag and Drop feature for my chat input box. If a junior developer is tasked with this, the senior developer can easily have the LLM generate a summary of their conversation like so:

https://beta.gitsense.com/?chat=d36e0282-4326-46cf-83b1-4207...

At this point, the senior developer can see if anything is missed; if desired, they can fork the conversation to ask the LLM questions like "Was this asked?" or "Was this mentioned?"

And once everybody is happy, you can have the LLM generate a PR title and message like so:

https://beta.gitsense.com/?chat=8aa19528-5891-4dda-9a88-247a...

All of this took me about 10 minutes, which would have taken me an hour or maybe more without LLMs.

And from here, you are now ready to think about coding with or without LLM.

I think with proper tooling, we might be able to accelerate the learning process for junior developers as we now have an intermediate layer that can better articulate the senior developers' thoughts. If the junior developer is too embarrassed to ask for clarification on why the senior developer said what they did, they can easily ask the LLM to explain.

The issue right now is that we are so focused on the moon shots for LLM, but the simple fact is that we don't need it for coding if we don't want to. We can use it in a better way to communicate and gather requirements, which will go a long way to writing better code faster.

AI agents will do the same job.

What will still matter is software that constrains what kind of data ends up in the database and ensures that data means what it is supposed to. That software will be created by local teams that know the business and the data. They will use AI to write the software and test it. Will those teams be “developers”? It is probably semantics or a matter of degree. Half the people writing advanced Excel spreadsheets today should probably be considered developers really.

Programming languages are languages to tell the computer what to do. In the beginning, people wrote in machine code. Then, high level languages like C and FORTRAN were invented. Since then we’ve been iterating on the high level language idea.

These LLM based tools seem to be a more abstract way of telling the computer what to do. And they really might, if they work out, be a jump similar to the low/high level split. Maybe in the future we’ll talk about low-level, high-level, and natural programming languages. The only awkwardness will be saying “I have to drop down to a high level language to really understand what the computer is doing.” But anyway, there were programmers on either side of that first split (way more after), if there’s another one I suspect there will still be programmers after.

Obviously, source allows human tuning, auditing, and so on. But taken at the limit, those aspects may eventually no longer be necessary. Just a riff here, as the thought just occurred.

Even the discussion around AI partially replacing coders is a direction towards commoditization.

We saw it crystal clear between the boom years, the trough, and the current recovery.

If you’re infinitely productive, then the solution to every problem is to just keep producing stuff, instead of learning to say no.

This means a lot of companies will overbuild, and then drown in maintenance problems and fail catastrophically when they can’t keep up.

And yet many companies aren't hiring developers right now - folks in the C suite are thinking AI is going to be eliminating their need to hire engineers. Also "demand" doesn't necessarily mean that there's money available to develop this code. And remember that when code is created it needs to be maintained and there are costs for doing that as well.

I'd love to see numbers around the "execs don't think they need engineers because of AI" factor. I've heard a few anecdotal examples of that but it's hard to tell if it's a real trend or just something that catches headlines.

Another data point is that there's been ~10 companies that I have been following and all of them have been shut down in the past year or so.

And the general feeling you get from the number of HN posts from people complaining about not being able to find jobs. This certainly hasn't been like that before.

And this kind of fear mongering is particularly irritating when you see that our industry already faced a similar productivity shock less than twenty years ago: before open source went mainstream github and library hubs like npm we used to code the same things over and over again, most of the time in a half-backed fashion because nobody had time for polishing stuff that was needed but only tangentially related to the code business. Then came the open-source tsunami, and suddenly there was a high quality library for solving your particular problem and the productivity gain was insane.

Fast forward a few years, does it look like this productivity gains took any of our jobs? Quite the opposite actually, there has never been as many developers as today.

(Don't get me wrong, this is massively changing how we work, like the previous revolution did, and how job is never going to be the same again)

These might not be big products, but who wants big products anyway? You always have to bend over backwards to trick them into doing what you want. You should see the crazy stuff my partner does to make google docs fit her use case...

Let's have an era of small products made by people who are close to the problems being solved.

There is a lot of work. Plenty of it just isnt super fun or interesting.

Aka Devs can move up the chain into what was traditionally product roles to increase development of new projects. This is using the time they have regain from more menial tasks being automated away.

I don't trust companies to translate that to, "We can do more now" rather than, "We can do more with less people now" though.

We really are in AI moment of iPhone. I never thought I would witness something bigger than the impact of Smartphone. There are insane amount of value that we could extract out. Likely in tens of trillions from big to small business.

We keep asking how Low Code or No Code "tools" could achieve custom apps. Turns out we are here via a different route.

>custom software because they'd need a team of 6 working for 12 months may now hire developers if they only need 2 working for 3 months to get something useful.

I am wondering if it be more like 2 working for 1 month?

Maybe devs will be replaced with QA, or become glorified QA themselves.

Most companies don't have a milelong backlog of coding projects. That's a uniquely tech industry-specific issue, and a lot of it is driven by the tech industry's obsessive compulsion to perpetually reinvent wheels.

Companies that would never have considered building custom software because they'd need a team of 6 working for 12 months may now hire developers if they only need 2 working for 3 months to get something useful.

No, because most companies that can afford custom software want reliable software. Downtime is money. Getting unreliable custom software means that the next time around they'll just adapt their business processes to software that's already available on the market.

This is viewing things too narrowly I think. Why do we even need most of our current software tools aside from allowing people to execute a specific task? AI won't need VSCode. If AI can short circuit the need for most, if not nearly all enterprise software, then I wouldn't expect software demand to increase.

Demand for intelligent systems will certainly increase. And I think many people are hopeful that you'll still need humans to manage them but I think that hope is misplaced. These things are already approaching human level intellect, if not exceeding it, in most domains. Viewed through that lens, human intervention will hamper these systems and make them less effective. The rise of chess engines are the perfect example of this. Allow a human to pair with stockfish and override stockfish's favored move at will. This combination will lose every single game to a stockfish-only opponent.

But the bit of data we got in this story is that a human wrote tests for a human-identified opportunity, then wrote some prompts, iterated on those prompts, and then produced a patch to be sent in for review by other humans.

If you already believed that there might be some fully autonomous coding going on, this event doesn’t contradict your belief. But it doesn’t really support it either. This is another iteration on stuff that’s already been seen. This isn’t to cheapen the accomplishment. The range of stuff these tools can do is growing at an impressive rate. So far though it seems like they need technical people good enough to define problems for them and evaluate the output…

Why not? It's still going to be quicker for the AI to use automated refactoring tooling than to manually make all the changes itself.

This was all in the default web chat UI.

https://chris-granger.com/2015/01/26/coding-is-not-the-new-l...

modelling has been , is , and will be the needed literacy..

No, work is never the core problem. Backlog of bug fixes/enhancements is rarely what determines the headcount. What matters is the business need. If the product sells and there is no/little competition, the company has very little incentive to improve their products, especially hiring people to do the work. You'd be thankful if a company does not layoff people in teams working on mature products. In fact, the opposite has been happening, for quite a while. There are so many examples out there that I don't need to name them.

India and Eastern EU will win far more (relatively) than expensive devs in the US or Western EU.

The first commit was half a page of code that read itself in, asked the user what change they'd like to make, sent that to GPT-4, and overwrote itself with the result. The second commit was GPT-4 adding docstrings and type hints.

Over 80% of the code was written by AI in this manner, and at some point, I pulled the plug on humans, and the last couple hundred commits were entirely written by AI.

It was a huge pain to develop with how slow and expensive and flaky the GPT-4 API was at the time. There was a lot of dancing around the tiny 8k context window. After spending thousands in GPT-4 credits, I decided to mark it as proof of concept complete and move on developing other tech with LLMs.

Today, with Sonnet and R1, I don't think it would be difficult or expensive to bootstrap the thing entirely with AI, never writing a line of code. Aider, a fantastic similar tool written by HN user anotherpaulg, wasn't writing large amounts of its own code in the GPT-4 days. But today it's above 80% in some releases [2].

Even if the models froze to what we have today, I don't think we've scratched the surface on what sophisticated tooling could get out of them.

[1]: https://github.com/reitzensteinm/duopoly [2]: https://aider.chat/HISTORY.html

I'm not too worried. If anything we're the last generation that knows how to debug and work through issues.

I suspect that comment might soon feel like saying "not too worried about assembly line robots, we're the only ones who know how to screw on the lug nuts when they pop off"

If you're working in a modern manufacturing business the fact that you do your work with the aid of robots is hardly a sign of despair

I think what we're all learning in real-time is that human technology is perpetually aimed at replacing itself and we may soon see the largest such example of human utility displacement.

I briefly looked into this 10 years ago since people kept saying it. There is no demand for COBOL programmers, and the pay is far below industry average. [0]

[0] https://survey.stackoverflow.co/2024/work/#3-salary-and-expe...

And most are too focused on learning whatever slop the industry wants them to learn, so they don't even know that it exists. We need 500 different object oriented languages to do web applications after all. Can't be bothered with learning a new paradigm if it doesn't pay the bills!

It's the most intuitive language I've ever learned and it has forever changed the way I think about problem solving. It's just logic, so it translates naturally from thought to code. I can go to a wikipedia page on some topic I barely know and write down all true statements on that page. Then I can run queries and discover stuff I didn't know.

That's how I learned music theory, how scales and chords work, how to identify the key of a melody... You can't do that as easily and concisely in any other language.

One day, LLM developers will finally open a book about AI and realize that this is what they've been missing all along.

The back and forth was agonising. They were all competent software engineers but communicating with them was often far more work than just writing the damn code myself.

So yes I do believe that our trade has changed forever. But the fact that some of our coworkers will be AIs doesn't mean that communicating with them is suddenly free. Communcation comes with costs (and I don't mean tokens). That won't change.

If you know your stuff really well, i.e. you work on a familiar codebase using a familiar toolset, the shortest path from your intentions to finished code will often not include anyone else - no humans and no AI either.

In my opinion, "LLMs are only marginally useful in coding" is not true in general, but it could well be true for a specific person and a specific coding task.

- This will enable more software to be built and maintained by same or fewer people (initially). Things that we wouldn't previously bother to do are now possible.

- More software means more problems (not just LLM-generated bugs which can be handled by test suites and canary deploys, but overall features and domains of what software does)

- This means skilled SWEs will still be in demand, but we need to figure out how to leverage them better.

- Many codebases will be managed almost entirely by agents, effectively turning it into the new "build target". This means we need to build more tooling to manage these agents and keep them aligned on the goal, which will be a related but new discipline.

SWEs would need to evolve skillsets but wasn't that always the deal?

https://news.ycombinator.com/item?id=42814509

However, it also highlights a key problem that LLMs don’t solve: while they’re great at generating code, that’s only a small part of real-world software development. Setting up a GitHub account, establishing credibility within a community, and handling PR feedback all require significant effort.

In my view, lowering the barriers to open-source participation could have a bigger impact than these AI models alone. Some software already gathers telemetry and allows sharing bug reports, but why not allow the system to drop down to a debugger in an IDE? And why can’t code be shared as easily as in Google Docs, rather than relying on text-based files and Git?

Even if someone has the skills to fix bugs, the learning curve for compilers, build tools, and Git often dilutes their motivation to contribute anything.

I more often heard the argument, they are not useful for them. I agree. If a LLM would be trained on my codebase and the exact libaries and APIs I use - I would use them daily I guess. But currently they still make too many misstake and mess up different APIs for example, so not useful to me, except for small experiments.

But if I could train deepseek on my codebase for a reasonable amount(and they seemed to have improved on the training?), running it locally on my workstation: then I am likely in as well.

If you mean just the name of the version in the prompt? No way.

If you mean all the libary and my code in the contextwindow?

Way too small.

Here's an example transcript where I did that: https://gist.github.com/simonw/6a9f077bf8db616e44893a24ae1d3...

But for my actual codebase, that is sadly not 100% clear code, it would require lots and lots of work, to give examples so it has enough of the right context, to work good enough.

While working I am jumping a lot between context and files. Where a LLM hopefully one day will be helpful, will be refactoring it all. But currently I would need to spend more time setting up context, than solving it myself.

With limited scope, like in your example - I do use LLMs regulary.

It is frustrating that any smaller tool or api seem to stump llms currently but it seems like context is the main thing that is missing and that is increasing more and more.

The idea is that I gather this data now and it may become useful in the future. Imagine getting a "helper AI" that still keeps your essence, opinions and behavior. That's what I'm hoping for with this.

My idea with this is inspired by that. It's just for personal use and to address my own needs.

I should have clarified, I'm only building this for myself and my own use, there are no plans to take it further than that. Basically, I am trying to learn while building something that satisfies my own needs.

Something I think about a lot is the impact of open source on software development.

25 years ago any time you wanted to build anything you pretty much had to solve the same problems as everyone else. When I went to university it even had a name - the software reusability crisis. At the time people thought the solution was OOP!

Open source solved that. For any basic problem you want to solve there are now dozens of well tested free libraries.

That should have eliminated so many programming jobs. It didn't: it made us more productive and meant we could deliver more value, and demand for programmers went up.

Individual developer productivity will be expected to rise. Timelines will shorten. I don't think we've reached Peak Software where the limiting factor on software being written is demand for software, I think the bottlenecks are expense and time. AI tools can decrease both of those, which _should_ increase demand. You might be expected to spend a month outputting a project that would previously have taken four people that month, but I think we'll have more than enough demand increase to cover the difference. How many business models in the last twenty years that weren't viable would've been if the engineering department could have floated the company to series B with only a half dozen employees?

What IS larger than before, IMO, is the talent gap we're creating at the top of the industry funnel. Fewer juniors are getting hired than ever before, so as seniors leave the industry due to standard attrition reasons, there are going to be fewer candidates to replace them. If you're currently a software engineer with 10+ YoE, I don't think there's much to worry about - in fact, I'd be surprised if "was a successful Software Engineer before the AI revolution" doesn't become a key resume bullet point in the next several years. I also think that if you're in a position of leadership and have the creativity and leadership to make it work, juniors and mid-level engineers are going to be incredibly cost effective because most middle managers won't have those things. And companies will absolutely succeed or fail on that in the coming years.

"Development" is effectively translating abstractions of an intended operation to machine language.

What I find kind of funny about the current state is we're using large language models to, like, spit out React or Python code. This use case is obviously an optimization to WASM, so a little closer to the metal, but at what point to programs (effectively suites of operations) just cut out the middleman entirely?

What tools would you tell a copilot dev to try? For example, I have a $20/mo ChatGPT account and asking it to write code or even fix things hasn't worked very well. What am I missing?

Just look at the options dialogue for Microsoft Word at least back in the day. It was pretty much everyone's pet feature over the last 10 years.

1. You should try Aider. Even if you don't end up using it, you'll learn a lot from it.

2. Conversations are useful and important. You need to figure out a way to include (efficiently, with a few clicks) the necessary files into the context, and then start a conversation. Refine the output as a part of the conversation - by continuously making suggestions and corrections.

3. Conversational editing as a workflow is important. A better auto-complete is almost useless.

4. Github copilot has several issues - interface is just one of them. Conversational style was bolted on to it later, and it shows. It's easier to chat on Claude/Librechat/etc and copy files back manually. Or use a tool like Aider.

5. While you can apply LLMs to solve a particular lower level detail, it's equally effective (perhaps more effective) to have a higher level conversation. Start your project by having a conversation around features. And then refine the structure/scaffold and drill-down to the details.

6. Gradually, you'll know how to better organize a project and how to use better prompts. If you are familiar with best practices/design patterns, they're immediately useful for two reasons. (1) LLMs are also familar with those, and will help with prompt clarity; (2) Modular code is easier to extend.

7. Keep an eye on better performing models. I haven't used GPT-4o is a while, Claude works much, much better. And sometimes you might want to reach for o1 models. Other lower-end models might not offer any time savings; so stick to top tier models you can afford. Deepseek models have brought down the API cost, so it's now affordable to even more people.

8. Finally, it takes time. Just as any other tool.

> A better auto-complete is almost useless.

That's not true. I agree that Copilot seemed unhelpful when I last tried it, but Cursor's autocomplete is extremely useful.

There are coordination costs to organising large amounts of labour. Costs that scale non-linearly as massive inefficiencies are introduced. This ability to scale, provide capital and defer profitability is a moat for big tech and the silicon valley model.

If a team of 10 engineers become as productive as a team of 100-1000 today, they will get serious leverage to build products and start companies in domains and niches that are not currently profitable because the middle managers, C-Suite, offices and lawyers are expensive coordination overhead. It is also easier to assemble a team of 10 exceptional and motivated partners than 1000 employees and managers.

Another way to think about it is what happens when every engineer can marshal the AI equivalent of $10-100m dollars of labour?

My optimistic take is that the profession will reach maturity when we become aware of the shift in the balance of power. There will be more solo engineers and we will see the emergence of software practices like the ones doctors, lawyers and accountants operate.

I hate the idea of building a business to hundreds/thousands of employees, I love startups and small but highly profitable businesses.

Having productivity be unleashed in this way with a small team of people I trust would be amazing.

The obstacles are in marketing, selling it, building a brand/reputation, integrating it with lots of 3rd party vendors, and supporting it.

So yes, you can build your own Salesforce, or your own Adobe Photoshop with a one-man crew much faster and easier. But that doesn't mean you, as an engineer can now build your own business selling it to companies who don't know anything about you.

when he was greener, he happened to work with some old fart... who managed to work 10x faster than others, with this trick: put all the tiles on the wall with a diluted cement-glue very quick, then moving one tile forces most other tiles around to move as well.. so he managed to order all the tiles in very short time.

As i never had the luxury of decent budget, since long time ago i was doing various meta-programming things, then meta-meta-programming.. up to extent of say, 2 people building and managing and enjoying a codebase of 100KLOC (python) + 100KLOC js... ~~30% generated static and unknown %% generated-at-runtime - without too much fuss or overwork.

But it seems that this road has been a dead end... for decades. Less and less people use meta-programming, it needs too deep understanding ; everyone just adds yet-another (2y "senior") junior/wanna-be to copy-paste yet another crud.

So maybe the number of wanna-bees will go down. Or "senior" would start meaning something.. again. Or idiotically-numbing-stoopid requirements will stop appearing..

A thing to point out is that management is itself a skill, and a difficult one, one where some organizations are more institutionally competent than others. It's reasonable to think of large-organization management as the core competency of surviving large organizations. Possibly the hypothetical atomizing force you describe will create an environment where they are poorly adapted for continuing survival.

After all, if your codebase is largely written by AI, it becomes entirely legal to copy it and publish it online, and sell competing clones. That's fine for open source, but not so fine for a whole lot of closed source.

This is a task that would likely have taken as long to write by hand as the AI took to do it, given how long the actual task took to execute. 98% of the work is find and replace

Don't get me wrong - this kind of thing is useful and cool, but you're mixing up the easy coding donkey work with the stuff that takes up time

If you look at the actual prompt engineering part, its clear that this prompting produced extensively wrong results as well, which is tricky. Because it wasn't produced by a human, it requires extensive edge case testing and review, to make sure that the AI didn't screw anything up. If you have the knowledge to validate the output, it would have been quicker to write it by hand instead of reverse engineering the logic by hand. Its bumping the work off from writing it by hand, to the reviewers who now have to check your ML code because you didn't want to put in the work by hand

So overall - while its extremely cool that it was able to do this, it has strong downsides for practical projects as well

I don’t get why people don’t understand that everything decomposes into other things.

You can draw the line for when AI will truly blow your mind anywhere you want, the point is the dominoes keep falling relentlessly and there’s no end in sight.

I draw the line, when the LLM will be able to help me with a novel problem.

It is impressive how much knowledge was encoded into them, but I see no line from here to AGI, which would be the end here.

For example: AI's smash translation. They won't ever beat out humans, but as an automated solution? They rock. Natural language processing in general is great. If you want to smush in a large amount of text, and smush out a large amount of other text that's 98% equivalent but in a different structure, that's what AI is good for. Same for audio, or picture manipulation. It works because it has tonnes of training data to match your input against

What AI cannot do, and will never be able to do, is take in a small amount of text (ie a prompt), and generate a large novel output with 100% accuracy. It simply doesn't have the training data to do this. AI excels in tasks where it is given large amounts of context and asked to perform a mechanistic operation, because its a tool which is designed to extract context and perform conversions based on that context due to its large amounts of training data. This is why in this article the author was able to get this to work: they could paste in a bunch of examples of similar mechanical conversions, and ask the AI to repeat the same process. It has trained on these kinds of conversions, so it works reasonably well

Its great at this, because its not a novel problem, and you're giving it its exact high quality use case: take a large amount of text in, and perform some kind of structural conversion on it

Where AI fails is when being asked to invent whole cloth solutions to new problems. This is where its very bad. So for example, if you ask an AI tool to solve your business problem via code, its going to suck. Because unless your business problem is something where there are literally 1000s examples of how to solve it, the AI simply lacks the training data to do what you ask it, it'll make gibberish

It isn't the nature of the power of the AI, its that its inherently good for solving certain kinds of problems, vs other kinds of problems. It can't be solved with more training. The OPs problem is a decent use case for it. Most coding problems aren't. That's not that it isn't useful - people have already been successfully using them for tonnes of stuff - but its important to point out that its only done so well because of the specific nature of the use case

Its become clear that AI requires someone of equivalent skill as the original use case to manage its output if 100% accuracy is required, which means that it can only ever function as an assistant for coders. Again, that's not to say it isn't wildly cool, its just acknowledging what its actually useful for instead of 'waiting to have my mind blown'

Like all the people surprised by Deepseek when it has been clear for the last 2 years there is no moat in foundation models and all the value is in 1) high quality data that becomes more valuable as the internet fills with AI junk 2) building the UX on top that will make specific tasks faster.

There are probably 10% of truly novel problems out there, the rest are just already solved problems with slightly different constraints of resources ($), quality (read: reliability) and time. If LLMs get good enough at generating a field of solutions that minimize those three for any given problem, it will naturally tend to change the nature of most software being written today.

But there's also bespoke problems. They aren't quite novel, yet are complicated and require a lot of inside knowledge on business edge cases that aren't possible to sum up in a word document. Having worked with a lot of companies, I can tell you most businesses literally cannot sum up their requirements, and I'm usually teaching them how their business works. These bespoke problems also have big implications on how the app is deployed and run, which is a whole different thing.

Then you have LLMs, which seem allergic to requirements. If you tell an LLM "make this app, but don't do these 4 things," it's very different from saying "don't do these 12 things." It's more likely to hallucinate, and when you tell it to please remember requirement #3, it forgets requirement #7.

Well, my job is doing things with lots of restraints. And until I can get AI to read those things without hallucinating, it won't be helpful to me.

LLMs do not think, they do not perform logic they are approximating thought. The reason why CoT works is because of the main feature of LLMs, they are extremely good at picking reasonable next tokens based on the context.

LLM are good and always have been good at three types of tasks:

- Closed form problems where the answer is in the prompt (CoT, Prompt Engineering, RAG)

- Recall from the training set as the Parameter space increases (15B -> 70B -> almost 1T now)

- Generalization and Zero shot tasks as a result of the first two (this is also what causes hallucinations which is a feature not a bug, we want the LLM to imitate thought not be a Q&A expert system from 1990)

If you keep being fooled by LLM thinking they are AGI after every impressive benchmark and everyone keeps telling you that in practice LLM are not good at tasks that are poorly defined, require niche knowledge, or require a special mental model that is on you.

I use LLM every day I speed up many tasks that would take 5-15 mins down to 10-120 seconds (worst case for re-prompts). Many times my tasks take longer than if I had done it myself because it’s not my work im just copying it. But overall I am more productive because of LLM.

Does LLM speeding up your work mean that LLM can replace Humans?

Personally I still don’t think LLM can replace Humans at the same level of quality because they are imitating thought not actually thinking. Now the question among the corporate overlords is will you reduce operating costs by XX% per year (wages) but reducing the quality of service for customers. The last 50 years have shown us the answer…

AI will blow my mind when it solves an unsolved mathematical/physics/scientific problem, i.e: "AI, give me a proof for (or against) the Riemann hypothesis"

That said, this is really brute forcing, not what the OP is asking for, which is providing a novel proof as the response to a prompt (this is instead providing the novel proof as one of thousands of responses, each of which could be graded by a function).

The idea that deep blue is in any way a general artificial intelligence is absurd. If you'd believed AI researchers hype 20 years ago, we'd have everything fully automated by now and the first AGI was just around the corner. Despite the current hype, chatgpt and co is barely functional at most coding tasks, and is excessively poor at even pretty basic reasoning tasks

I would love for AI to be good. But every time I've given it a fair shake to see if it'll improve my productivity, its shown pretty profoundly that its useless for anything I want to use it for

How are you defining apologists here? Anti-AI apologists? Human apologists? That's not a word you can just sprinkle on opposing views to make them sound bad.

Thanks to Simon for pointing out my point is encapsulated by the AI effect, which also offers an explanation:

"people subconsciously are trying to preserve for themselves some special role in the universe…By discounting artificial intelligence people can continue to feel unique and special.”

Those monsters

> Thanks to Simon for pointing out my point is encapsulated by the AI effect

And someone else pointed out that goes both ways. Every new AI article is evidence of AGI around the corner. I am open to AI being better in the future but it's useless for the work I do right now.

Seems pretty useful to me where I've read a bunch of papers on different variational autoencoder but never spent the time to learn the torch API or how to set up a project on the google.

In fact, it was so useful I was looking into paying for a subscription as I have a bunch of half-finished projects that could use some love.

Usually, there are hidden payoffs that motivate things that seem like waste.

Hiring someone to remodel a bathroom is hard enough, now try hiring a contract software engineer, especially when you don't have budget authority!

That said, I heard about a fire chief last year who had to spend two days manually copying and pasting from one CRM to another. I wish I could help people like that know when to pay someone to write a script!

I imagine even in that role figuring out how to hire someone so solve a problem would still take longer than manually crunching through that themselves.

Admittedly, I haven't looked too hard, but how could I do that with a model from, say, Ollama and run exclusively on my machine?

After a very quick reading of their pages it does not seem so.

Hopefully I am wrong...

Look at the code that was changed[0]. It's a single file. From what I can tell, it's almost purely functional with clearly specified inputs and outputs. There's no need to implement half the code, realize the requirements weren't specified properly, and go back and have a conversation with the PM about it. Which is, you know, what developers actually do.

This is the kind of stuff LLMs are great at, but it's not representative of a typical change request by Java Developer #1753 at Fortune 500 Enterprise Company #271.

[0] https://github.com/ggerganov/llama.cpp/pull/11453/files

(That's not to say it isn't a valid argument.)

Short answer: LLMs are amazingly useful on large codebases, but they are useful in different ways. They aren't going to bang out a new feature perfectly first time, but in the right hands they can dramatically accelerate all sorts of important activities, such as:

- Understanding code. If code has no documentation, dumping it into an LLM can help a lot.

- Writing individual functions, classes and modules. You have to be good at software architecture and good at prompting to use them in this way - you take on the role of picking out the tasks that can be done independently of the rest of the code.

- Writing tests - again, if you have the skill and experience to prompt them in the right way.

That's not at all what the GP was saying, though:

> There's no need to implement half the code, realize the requirements weren't specified properly, and go back and have a conversation with the PM about it. Which is, you know, what developers actually do.

> This is the kind of stuff LLMs are great at, but it's not representative of a typical change request by Java Developer #1753 at Fortune 500 Enterprise Company #271.

> Writing individual functions, classes and modules. You have to be good at software architecture and good at prompting to use them in this way - you take on the role of picking out the tasks that can be done independently of the rest of the code.

If you have enough skill and understanding to do this, it means you already have enough general software development experience and domain-specific experience and experience with a specific, existing codebase to be in rarefied air. It's like saying, oh yeah a wrench makes plumbing easy. You just need to turn the wrench, and 25 years of plumbing knowledge to know where to turn it.

> Writing tests - again, if you have the skill and experience to prompt them in the right way.

This is very true and more accessible to most developers, though my big fear is it encourages people to crap out low-value unit tests. Not that they don't love to do that already.

Yes, exactly. That's why I keep saying that software developers shouldn't be afraid that they'll be out of a job because of LLMs.

It's like the transition from hand-crafted furniture to assembly line mass produced furniture.

The assembly line brought its own excitement, but that excitement was not to be found on the actual assembly line.

For whatever reason a good part of the joy of day to day coding for me was solving many trivial problems I knew how to solve. Sort of like putting a puzzle together. Now I think higher level and am more productive but it's not as much fun because the little easy problems aren't worth my time anymore.

How do you get these tools to not fall over completely when relying on an existing non-public codebase that isn't visible in just the current file?

Or, how do you get them to use a recent API that doesn't dominate their training data?

Combining the both, I just cannot for the life of me get them to be useful beyond the most basic boilerplate.

Arguably, SIMD intrinsics are a one-to-one translation boilerplate, and in the case of this PR, is a leetcode style, well-defined problem with a correct answer, and an extremely well-known api to use.

This is not a dig on LLMs for coding. I'm an adopter - I want them to take my work away. But this is maybe 5% of my use case for an LLM. The other 95% is "Crawl this existing codebase and use my APIs that are not in this file to build a feature that does X". This has never materialized for me -- what tool should I be using?

Paste in the documentation or some examples. I do this all the time - "teaching" an LLM about an API it doesn't know yet is trivially easy if you take advantage of the longer context inputs to models these days.

I'd be happy to share the example with you.

I use this technique all the time. Here's one written-up example: https://simonwillison.net/2024/Mar/30/ocr-pdfs-images/ - transcript here: https://gist.github.com/simonw/6a9f077bf8db616e44893a24ae1d3...

I'm at work so I can't try again right now, but last I did was use claude+context, chatGPT 4o with just chatting, Copilot in Neovim, and Aider w/ claude + uploading all the files as context.

I even went so far as to grab relevant examples from https://github.com/bevyengine/bevy/tree/latest/examples#exam... , adding relevant ones as I saw fit.

It took a long time to get anything that would compile, way longer than just reading + doing, and it was eventually wrong anyway. This is a recurring issue with Rust, and I'd love a workaround since I spend 60+h/week writing it (though not bevy). Probably a skill issue.

Or I'd more likely start by asking for options: "What are some options for adding a button to that left panel?" - then pick one that I liked, or prompt it to use an approach it didn't suggest.

After it delivered code, if I didn't like the code it had used I'd tell it: "Don't use that class, use X instead" or "define a separate function for that callback" or whatever.

That makes sense. It doesnt help me get to 11 if I don't know the basics myself though.

But I think it’s still much too early for any form of “can we all just call it settled now? In this case, as we all know, lines of code is not a useful metric. How many person hours were spent doing anything associated with this PR’s generation and how does that compare to not using AI tools, and how does the result compare in terms of the various forms of quality? That’s the rubric I’d like to see us use in a more consistent manner.

It's a bit like what happens with "illusion of knowledge" or "illusion of understanding". When one knows the topic, one can correct the output of AI. When one doesn't, one tends to forget it can be inaccurate or plain wrong.

I'm not so sure there isn't a bit of bluster in there. Imagine when you hand-coded in either machine code or assembly and then high level languages became a thing. I assume there was some handwringing then as well.

This is a key insight - the trade has changed.

For a long time, hoarding talent - who could conceive and implement such PRs - was a competitive advantage. It no longer is because companies can hire and get similar outcomes, with fewer and mediocre devs.

But at the same time, these companies have lost their technological moat. The people were the biggest moat. The hoarding of people were the reason why SV could stay ahead of other concentrated geographies. This is why SV companies grew larger and larger.

But now, anyone anywhere can produce anything and literally demolish any competitive advantage of large companies. As an example, literally a single Deepseek release yesterday destroyed large market cap companies.

It means that the future world is likely to have a large number of geographically distributed developers, always competing, and the large companies will have to shed market cap because their customers will be distributed among this competition.

It's not going to be pleasant. Life and work will change but it is not merely loss of jobs but it is going to be loss of the large corporation paradigm.

Do you have a link to that?

Then in the 00s, the computing resources became widely available. The bottleneck was the people who could build interesting things. Imagine a third world country with access to AWS but no access to developers who could build something meaningful.

With these models, now these geographically distributed companies can build similarly high quality stuff.

R1 IS the example of something that previously only could be built in the bowels of large SV corporations.

Nobody was “destroyed” - a handful of companies had their stock price drop, a couple had big drops, but most of those stocks are up today, showing that the market is reactionary.

The point still is: Software/engineering is no longer the moat creator.

Notice how Apple and Meta stocks went up last 2 days?

Apple has a non-software moat: Their devices.

Meta has a non-software moat: their sticky users.

So does Microsoft, and Google to an extent with their non-software moat.

But how did they build the most in the first place? With software that only they could develop, at a pace that only they could execute, all because of the people they could hoard.

The companies of the future can disrupt all of them (maybe not apple) very quickly by just developing the same things as say Meta and "at the same quality" but for cheaper. The engineers moat is gone. The only moat meta has is network effects. That's one less barrier for a competing company to deal with.

Useful, sure, in that it saved some time in this particular case. But most of the AI-generated code I interact with is a hot unmaintainable mess of very verbose code, which I'd argue actually hurts the project in the long term.

That sounds like you're working with unskilled developers who are landing bad code.

I am 30 and even before AI, I NEVER thought for a moment I would get to keep coding until I am f*king 65, lol

There are so many potential trajectories going forward for things to turn sour, I don't even know where to start the analysis. The level of sophistication an AI can achieve has no upper bound.

I think we've had a good run so far. We've been able to produce software in the open with contributions from any human on the planet, trusting it was them who wrote the code, and with the expectation that they also understand it.

But now things will change. Any developer, irrespective of skill and understanding of the problem and technical domains can generate sophisticated looking code.

Unfortunately, we've reached a level of operational complexity in the software industry, that thanks to AI, could be exploited in a myriad ways going forward. So perhaps we're going to have to aggressively re-adjust our ways.

Yes, AI will enable exponentially more people to write code, but that's not a new phenomenon - bootcamps enabled an order of magnitude more people to become developers. So did higher level languages, IDEs, frameworks, etc. The march of technology has always been about doing more while having to understand less - higher and higher levels of abstraction. Isn't that a good thing?

The cognitive reality of AI, and more specifically of AI+Humans in the context of a social and globally connected world, is on a higher level of sophistication and can unfold much faster, which in turn might generate entirely unexpected trajectories.

You have to spend a lot of time experimenting with them to develop good intuitions for where they make sense to apply.

I expect the people who think LLMs are useless are people who haven't invested that time yet. This happens a lot, because the AI vendors themselves don't exactly advertise their systems as "they're great at some stuff and terrible at other stuff and here's how to figure that out".

I’d be interested in seeing how much time they spent debugging the generated code and and how long they spent constructing and reconstructing the prompts. I’m not a software developer anymore as my primary career, so if the entire lower-half of the software development market went away catering wages as it did, it wouldn’t directly affect my professional life. (And with the kind of conceited, gleeful techno-libertarian shit I’ve gotten from the software world at large over the past couple of years as a type of specialized commercial artist, it would be tough to turn that schadenfreude into empathy. But we honestly need to figure out a way to stick together or else we’re speeding towards a less mechanical version of Metropolis.)

When I see claims like this I suspect that either people around me somehow 10x better at promoting or they use different models.

Sometimes this works! But it's not guaranteed - this isn't their core strength, especially once you get into really deep knowledge of complex APIs.

They are MUCH more useful when you use them for transformation tasks: feed in examples of the APIs you need to work with, then have them write new code based on that.

Working effectively with LLMs for writing code is an extremely deep topic. Most people who think they aren't useful for code have been mislead into believing that the LLMs will just work - and that they don't first need to learn a whole bunch of unintuitive stuff in order to take advantage of the technology.

There is a space for learning materials here. I would love to see books/trainings/courses on how to use AI effectively. I am more and more interested in this instead of learning new programming language of the week.

I 100% agree with you our trade is changed forever.

On the other hand, I am writing like 1000+ LOC daily, without much compromise on quality and my mental health, and thought of writing some code that is necessary but feels like a chore is not longer the case. The boost in output is incredible.

But already I hire less and less developers for smaller tasks. The things that I‘d assign to a dev in Ukraine to explore an idea, do a data transformation, make a UI for the internal company tool. I can do these things quicker with llm than trying to find a dev and explain the task.

Once current AI gets good enough, the people micromanaging parts of it will do more to hinder the process than to help it.

One person setting the objectives and the AI handling literally everything else including brainstorming issues etc, is going to be all that's needed.

A person just setting the prompt and letting the AI do all the work is not adding any additional value. Any other person can come in and perform the exact same task.

The only way to actually provide differentiation in this scenario is to either build your own models, or micromanage the outputs.

> You're not expecting it to always be right, are you?

I think another thing that gets lost in these conversations is that humans already produce things that are "wrong". That's what bugs are. AI will also sometimes create things that have bugs and that's fine so long as they do so at a rate lower than human software developers.

We already don't expect humans to write absolutely perfect software so it's unreasonable to expect that AI will do so.

I want to stay in Helix and find a workflow that “just works”. Not sure even what that looks like yet

I feel like i want a more intuitive, natural process. Purely for illustration -- because i have no idea what the ideal workflow is -- I'd want something that could allow for large autocomplete without changing much. Maybe a process by which i write a function, args, docstring on the func and then as i write the body autocomplete becomes multiline and very good.

Something like this could be an extension of the normal autocomplete that most of us know and love. A lack of talking to an AI, and more about just tweaking how you write code to be very metadata rich so AIs have a rich understanding of intent.

I know there are LLM LSPs which sort of do this. They can make shorter autocompletes that are logical to what you're typing, but i think i'm talking about something larger than that.

So yea.. i don't know, but i just know i have hated talking to the LLM. Usually it felt like "get out of the way, i can do it faster" sort of thing. I want something to improve how we write code, not an intern that we manage. If that makes sense.

I'm currently trying to figure out how it works with my editor, though. Ie i don't want to leave my tooling of choice, Helix editor.

AI coding, for all its flaws now, is the first thing that takes a chunk out of this, and there is a HUGE backlog of good-but-not-great ideas that are now viable.

That said, this particular story is bogus. He "just wrote the tests" but that's a spec — implementing from a quality executable spec is much more straightforward. Deepseek isn't doing the design, he is. Still a massive accelerant.

LLMs seem to do well at any kind of mapping / translating task, but they seem to have a harder time when you give them either a broader or less deterministic task, or when they don’t have the knowledge to complete the task and start hallucinating.

It’s not a great metric to benchmark their ability to write typical code.

How much hardware efficiency have we left on the the table all these years because people don't like to think about optimal use of cache lines, array alignment, SIMD, etc. I bet we could double or triple the speeds of all our computers.

This is why the concerns from Keynes and Russel about people having nothing to do as machines automated away more work ended up being unfounded.

We fill the time... with more work.

And workers that can't use these tools to increase their productivity will need to be retrained or moved out of the field. That is a genuine concern, but this friction is literally called the "natural rate of unemployment" and happens all the time. The only surprise is we expected knowledge work to be more inoculated from this than it turns out to be.

Forever? Hell, it hasn't even existed for a lifetime yet.

- Avg. life expectancy in USA: 77.5 years

- 2025 - 77.5 = 1947.5

- In 1945, Turing published "Proposed Electronic Calculator"

- The first stored-program computer was built in 1948

- The term "software engineering" wasn't used until the 1960s

If you want to define "software engineering" such that it is more than 77.5 years old, that's fine. But saying that software engineering is less than 77.5 years old is clearly a reasonable stance.

Please stop berating me for a perfectly harmless and reasonably accurate statement. If you're going to berate me for anything, it should be for its brevity and lack of discussion-worthy content. But those are posted all the time.

In fact, from a distance seen, the software development pattern in AI times stays the same as it was pre-AI, pre-SO, pre-IDE as well as pre-internet.

Just to say, sw developers will still be sw developers.