It seems to me, so far, everyone moved one level up.

- A layperson can now build one a solo developer can do

- A solo dev can now build what an agency of web development can do

- An agency of web development can now build native apps similar to what large corporation can do

- Large corporation can now tackle even more ambitious projects

Which makes sense given what got automated. This is with the current tech, people still exploring the full potential, but if that turns out to be the case then I'd argue the software market will grow substantially and we are just having an adjustment period.

This matches my experience. My solo projects are now bigger than I ever would have accepted alone. The one I’m going to finish soon is one I actually refused a year ago because it was too big.

It’s the top of the chain that I wonder about. Agentic development is so fast (and in the process I’ve developed so good) that I’m thinking there is actually a maximum size a company doing this work could get. Beyond that top end size the management overhead is what’s limiting or the market size total. Maybe not, maybe mega dev houses will find other problems to solve, but I have a hard time imagining it.

I do suspect there will be many mega projects. Things like new operating systems, new apps ecosystem (not just apple/android), new virtual reality environments, massive interconnected web of agents, in-house models etc, also alot of re-writes and update of existing infrastructure.. competitors to existing social networks and many established players..I think the entire software ecosystem will grow larger, wider and deeper from all directions.

From what I have seen the pie will get way larger, but there is growth pain and adjustment period for sure.

But to your point, I also think solo devs/freelancer are now seeing the most gains, that's because they can adapt the fastest and they don't need to deal with existing overheads.

Larger organizations might need more tooling/agents and better internal processes before they can see the full potential. I don't think ww, as an industry, are there yet, this tech started truly working less than a year ago.

Yeah that is how I see it.

In Software Engineering, we learned about requirements, testings, system design, UMLs, etc, and those seems to be more relevant than ever.

Agile is dead. It presumed writing the code was the slowest part of the cycle. Now it makes more sense to only start writing code when the requirements are known as the code is quick and low cost to change if/when the requirements change later.

There are two problems that arise from cheap code:

1. You get complexity back at the speed that you add code. Also the complexity compounds.

2. As a human you are still responsible for your code, and you need to understand how the important parts of the code base work.

When you combine these problems, you get a complicated code base where you don't understand the important parts.

That is why software design is getting a comeback. It actually helps with both problems. Less complexity and more understanding.

Results and output are undeniable, unless you are delusional or in denial.

Worry not, for I am using Claude right now. I would never question the doctrine of AI usefulness and productivity. Please scrap that J'accuse draft, sir, for I would never commit blasphemy against AI, I promise.

I stopped writing code manually more than a year ago. I've experienced the 100x, even perhaps the 1000x he mentions, and I still think he's fucking psychotic.

Not reading generated webapp code is one thing. Blindly commiting OS code is a whole different dimension, as is writing production code in a language you don't even know how to read.

For varying definitions of results.

It's still early days, I'm hesitant to claim the death of software engineering. It's good now because LLMs were all trained on actual human output. One possible future is a slop death spiral.

I sure as hell am never again releasing human-authored open-source in a way that can be scraped. My Github is now relegated to the lowest quality slop from the cheapest models.

Because it does take some skills, judgement, taste, knowledge, time and effort to build things. He said it is not very different from directing a team of contractors, and also said that a 10x dev in now 1000x with a tool like this. He also gave the parallel of photography to address this point, that people were forced to be more creative and adapt.

But I assume you didn't use to build anything substantial.

> it does take some skills, judgement, taste, knowledge, time and effort to build things

As of now, but we are talking in a perspective.

People are not well organised.

Business people I work with tend to have all kind of ideas in different places, I cannot count all the Trello boards they have abandoned. Users are usually lazy and don't want to fill in data properly, well yeah chatbox with llm is cool interface, but you still have to enforce structure for data so it is useful.

With AI problem is still there "garbage in, garbage out", models are not going to imagine correct data to fill in blanks, in the end if you need someones birthday, someone has to type it in.

Web app I am working on is organised only because we get engineers and quality assurance and we get paid for maintaining application. Data is structured and we can deliver insights because the application enforces structure.

There are far more requirements than AI can deliver on its own.

>and also said that a 10x dev in now 1000x with a tool like this

Yeah, I'm sure you are doing ~4 years worth of work per day. Get real Jesus Christ.

1. he is saying md/english is the new source code.. 2. yes - it is different that is geared towards english and very well supported by LLMs that is why it is being used in memory and instructions 3. llms are deterministic enough to translate adequately described specs into working system, the idea here is reason in md for core flow etc, and then verify with test cases

this not perfect but he is describing a real trend, so listen with open mind.

Well summarized, but I believe this is sadly why we're seeing a decline in software quality all over. And if people keep following this trend for libraries and core utilities... yikes things will get bad.

Yeah but keep in mind this tech only started to work last year? People still figuring it out, and I'm sure we will have more robust tooling, processes around it down the road.

The upside is that we are able to deploy more cognitive power into problems, security, edge cases, something that uses be to scarce. A lot of the people feeling insecure mainly because they benefited from that scarcity. But we will have more software deployed, I'd argue better, and larger, and this means the pie of software is getting bigger, the market is getting larger, deeper into the economy.

You missed the entire point of the post..the author is arguing docs in md are the src...

But we already have a folder for docs? It's called "docs". If the docs are the source code, that's fine, but that doesn't mean we have to move them into the source code folder. We already have somewhere to put them! The end goal should be for the source code folder to be in the .gitignore, same as you would with object files... but if the docs are in there, now you're stuck.

Traditionally docs were for humans as a reference.

This is not doc, this is an .md file as a src to be used by LLMs to generate code. Therefore they are src files but in english.

No, this is not a source file to be used to generate code. It's a spec to be used to build the code to - same as any other document. Aside from the fact that docs can be in any format - not merely .md - they do not belong in `src/`. Why? Well for one, many of my projects have multiple `src/` directories because they involve multiple binaries. But the documentation used to generate that source is in the project, not the `src/` directory of one of its binaries. I'm building a video streaming site that uses one server for the SFU, one server for the web interface, one server for the websocket connections, as well as STUN and TURN servers. None of the project works unless all these separate binaries are working together and communicating. Which `src/` directory should I place these markdown files in? What about the `.sql` files I use to spec out the database schema before passing it off to the LLM? What about the mermaid files, code snippets, `.txt` files, and data files used as part of the documentation project? Should they all go in `sfu/src/md/`? No. The project is one whole with multiple `src/` directories and they all require their own documentation. Beyond that they need access to each other's documentation so that when the agent is working on one part of the system it can still be aware of how the other pieces operate. Documentation should absolutely be under version control, but placing it in the `src/` directory is plainly the wrong call. And there is more documentation than just markdown. This was a shower thought that wasn't completely fleshed-out (and the article admits it wasn't) and never should've made it to the front page of HN.

This is an experimental thought. If people are vibe coding apps without looking at code, the argument here is that maybe ad-hoc prompts is not the best way to capture that because you lose the instructions. So the proposal, why not have those instructions saved as markdown files at least we have a reference in English.

We don't look at binaries, we don't look at assembly, we work with high level languages. The specs were for developers to translate to programming primitives, but if the translation is largely automated, then the specs will become the code and we will need better ways to manage those, and I think the IDEs are gradually trending that way, look at all the most recent agentic dev tools, it surely follows that trend.

With respect to not having this piece on HN. If the author is seeing many organizations doing this practice, then why he would not share that empirical observation? is it only because it is against your pure world and abstractions? Just the recent leak for the Muse agent shows that most of the system behaviour is written in markdown.

Whether you like it or not, technology never care about purest and idealist, it evolve under pressure of deliveries and pragmatic choices, and if there is such a pressure, which the author claims to be, then HN is the medium to share it.

I like how you wrote "the argument here is that maybe ad-hoc prompts is not the best way to capture that because you lose the instructions" as if you didn't begin this thread by contradicting my statement "Docs in VCS, yes." and claiming I missed the entire point of the post. It seems you've now agreed with me and yet still somehow wish to argue. I think you've missed the point of my post. You should reflect on that.

But these are NOT docs in VCS. Docs in VCS were for references for developers. The ask here is to treat them as the source for instructions.

Maybe I'm misunderstanding you, I don't know.

Of course the src directory is in VCS - it's arguably the entire point of the VCS. The entire project - including documentation - should be in VCS. Documentation is not source and should not be treated like it. But it is crucial to generating the source and always has been treated as a second-class consideration. Now that we have AI agents that can handle all the fine details of keeping the documentation up to date, I believe. We seem to be in agreement that docs should be under revision control. So the only point we seem to disagree on is where they go. My original claim was that they don't belong under the src directory. I still maintain that position. You could say that the broader point of the article was to put them under VCS and I started out with that position so there is no disagreement there. I just think it's poorly thought-out to place them under the src directory and it's even more shortsighted to place the docs in a subdirectory called 'md'. To me, these seem like the thoughts of someone who is just discovering how to craft code with the assistance of AI: They're good initial instincts, and potentially just a handful of completed projects away from a better solution, which is what people have been doing since before AI: Keep the docs separate. Keep them under revision. Keep them up to date. But documentation is not source, and even if you specify the project in intricate detail you're not going to get the same deterministic result by piping them through the same AI. And that's always been the way documentation has worked: It specifies things in as much detail as we can, but in the end someone has to translate that into source code. And typically the person writing that source code has to make decisions or trade-offs that were never specified in the docs. Now with AI agents we're able to back-port every line of reasoning into the docs and create much better and more up-to-date documentation, and that's exactly how I build with AI. But we're not able to treat the documentation as if it's a deterministic system that will generate the same outputs each time. Therefore it is meaningfully different from source code and should be treated as such. (Although it should be kept very close to the source code in a structure that is intuitive and appropriate for the project.)

In any event: If we're talking past each other or simply not understanding one another then I thank you for a respectful conversation.

I agree with this, and that's how I do it.

I don't think we are at a position to claim that documentation are the source, though to your point and the author's point as well, it serving more purpose now then what used to have.

I would say that this field is evolving really fast and we might consider and revise some practices. So I try to keep as much as open mind as possible.

So, if .md is the new "source", target LLM generated sources should be removed from VCS?

Obviously, that's the correct end result. We're just not quite there yet.

yet is extremely load-bearing here.

Like people talking about typos not substance when discussing a subject and have nothing better to add.. annoying

"Engineering is the practical science of designing, building, and testing structures, machines, systems, and processes to solve real-world problems"

Did this system go through: design? yes, building: yes, testing: yes, is it a system: yes, does it solve real-world problem: yes.

but markdowns and LLMs with their fuzzy probabilistic feelings are beneath you i assume? you can ignore the fact that we have intelligence deployed to the billions, understand english, follow instructions..yeah, in case you missed, machines can now understand english better than you and me.

You conveniently omitted the critical word: science. Not nearly everything that involves design and those others is engineering. You know, the whole "necessary but not sufficient" thing in logic? Engineering is almost diametrically opposite to "vibing", and trying to call prompting-based LLM coding "engineering" is a massive insult against all real engineers who know that vibing can get people maimed or killed.

You are generalizing all llm-aided building to "vibing", which is not the case..and most engineering are based on science but they are not scientist (i.e discovering new science).

I think of a lot of people with this mindset never built anything substantial with the new tools to understand the new set of challenges with these processes and systems. It makes sense given your/their negative take on it which doesn't allow any room for exploration.

I think it is mostly pride issue honestly, because you use terms such "insult" and "real engineers etc". Some are learning and using those new tools and others are refusing given their pride. Similar to how Blackberry executives dismissed iPhone as a toy, and the rest is history.

https://www.news18.com/photogallery/business/in-2007-blackbe...

I invite you to build something substantial with those tools on the side.

If the problem was solved by anyone before or if a similar problem has been solved, then LLMs seem to be able to solve them which is an astonishing piece of technology.

I'm personally not sure if it can come with original thinking and techniques to solve completely novel problems. For that, some imagination and thinking outside the box are required, and I doubt the current architecture can do any of this.

What's an example of a completely novel problem?

I don't know..I doubt for example it can come up with special relatively if it has knowledge up until 1905.

But I think that is what makes it so good at coding, because coding and building software in general has a lot of repeated problems in different context. Same thing for human lives, many think their story or situation are unique, but reality is that the shape of human life has been repeated many many times.

I'd say novel math or scientific theories..let us say we send a robot to space, and we ask to build a colony. A lot of the challenges this robot will face will be novel, it could use inspirations of what humans did on earth, but it might get stuck when things don't work as expected and training data has nothing to build on..but then again we might teach it how to run experiments etc, which would result in data that it can use..but some of those experiments might require imagination or breakthrough in understanding..my guess is that it will get stuck there...

The Lorentz transformations were pretty close to special relativity https://en.wikipedia.org/wiki/Lorentz_transformation I don't claim that I could have discover it, but in a parallel universe without Einstein I expect it to be discovered, perhaps 10 years later, but there were a lot of breadcrumbs in 1904.

General relativity is harder, but Poincare was somewhat oriented in the right direction. Perhaps AI can discover the final step.

Quantum mechanics is harder. You need like 25 years and a few unintuitive leaps to discover it. I guess it's too hard for AI in 2026, but remember to check again in 2027.

I think the current architecture is limited.

To quote Einstein directly:

-----

Viereck (Interviewer): How do you account for your discoveries? Through intuition or inspiration?

Einstein: Discussing intuition and his confidence in relativity, noting he was convinced the 1919 eclipse would confirm his hypothesis.

Viereck: Then you trust more to your imagination than to your knowledge?

Einstein: I am enough of the artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.

-----

I think we need more breakthroughs to build AI that can "draw freely upon imagination" to quote Einstein describing his process.

That is just my guess.

«Whether you stand on the shoulders of giants or on a pile of agents, the result is the same: you see a little further.»

David Hilbert presented the field equations of general relativity within a few weeks of Einstein, so if anything GR was more sure to appear than SR, which took years for others to even notice (Einstein became famous only after the 1919 experiment that confirmed GR). Pertinently to the recent Navier-Stokes drama, there was very little controversy between the two and they both admitted that the other got some aspect better.

https://en.wikipedia.org/wiki/General_relativity_priority_di...

Yes of course he is going to use resources around him, that is not the point. It took a leap of imagination to apply it the way he did and think differently.

And this again because it's a solid argument and popular example of human ingenuity.

https://mathoverflow.net/q/511601 is a fun little math problem that came up in one of my projects, I didn't have any reason to expect it to be particularly tough, but none of the models I've thrown at it have been able to solve it past a few minor reductions and special cases.

I expect that there is some relatively easy-to-state solution to this problem, but that it's different in form from what most existing proofs and tools yield. Perhaps if I dumped millions of dollars into it an agent might chance on the solution. Or perhaps my luck is such that my fun little problem is truly intractable...

Well it's an old one at this point, but the story around the invention of the 1-time pad is pretty interesting. Long story short, a new engineer who didn't know the problem was considered "impossible" was tasked with sorting it out, and he did. I'm sure I left out a lot of details.

Why was this considered "impossible?"

It's a brilliant idea, of course. But being considered "impossible" means it was considered previously and decided to be impossible. No?

I mean, crpytographically, it's ultra-trivial. You "just" need to solve the logistical issues of (1) shortwave radio existing (2) figuring out how to make sure your field agents possess and are not caught with the disposable one-time codes. I am surprised anybody would consider that impossible.

(I hope I am not downplaying the brilliance of the one-time pad idea itself)

A child walking for the first time. Novelty is easiest agent-relative. A problem is novel for an agent if there is no prior experiences of techniques which work to solve it.

Is that a completely novel problem? Babies spend roughly a year watching us walk before they do so.

They also have custom brain bits evolved to aid in this task

I was defining novelty somewhat more narrowly. The 'program' a child must learn concerns the coordination of its sensory-motor system. It has no prior experience of similar programs in the program-class Walking (ie., the internal sensory-motor actions needed to walk) . So we could call the problem of learning to walk a novel one for that child.

I'd be surprised if direct observation of parents etc. played much of a direct role in learning to walk. I would guess it more furnishes the child's imagination so it can simulate itself walking -- rather than the statistical AI approach of 'learning the distribution of walking patterns in visual sensation'.

The ability to simulate possible programs is one of the capacities which enable coping with novel circumstances. My guess is the child learns to walk by updating its simulation of what it needs to do in order to walk, by its attempts to walk.

This simulation<->sensory-motor-update loop is missing in LLMs, for example.

>It has no prior experience of similar programs in the program-class Walking

Crawling?

Some animals walk within minutes of being born. Of course on four legs it's probably easier.

Walking is actually innate behaviour, it just occurs relatively late in maturation for humans.

>A child walking for the first time

Um, I'm not sure if you've noticed, but we have bipedal robots that walk and run rather well now.

https://docs.nvidia.com/learning/physical-ai/index.html

https://www.nvidia.com/en-us/use-cases/robot-learning/

"Find a way to connect quantum maths with special relativity maths Waves hands, and make no mistakes"

"Prove or disprove string theory in pure mathematics, reply in Caveman speech"

That is solved https://en.wikipedia.org/wiki/Dirac_equation

All the news from the CERN including the Higgs boson include under the hood those transformation or a slightly more modern variant.

The hard part is mixing General Relativity and Quantum Mechanics.

>Find a way to connect quantum maths with special relativity maths Waves hands, and make no mistakes

I think you mean general relativity, connecting quantum mechanics with special relativity is just QFT

Anything that an ai can do is not novel /s

You jest, but this is the content of a considerable number of serious posts here on HN.

this appears to be where the goalposts are being moved to, indeed.

just because humans couldn't solve does not mean the necessary technique were not already discovered...we have agents that don't get tired and has access to all humanity knowledge, the building blocks could be there already..

this is not moving the goalposts, this is try to understand what this tech truly able and not able to do.

Actually I think this is true, remove the s.

Reminds of what Einstein said, imagination is more important than knowledge..might be his deepest insight ever.

He needed his friend and math genius, Marcel Grossman, to turn his imagination into a workable theory. AI may be our own personal Marcel Grossman at this point.

Good analogy, yeah make sense.

Here is his quote:

"Imagination is more important than knowledge. For knowledge is limited, whereas imagination encircles the world,” means that facts alone only describe what currently exists, while imagination allows us to discover what is yet unproven or unbuilt"

This probably sums up the current AI limitation nicely.

Will be downvoted for sure, but here we go:

They can't think that a software can be written, designed and maintained in English or higher constructs.

It is binary of either vibe coded app, or worshipping the code that they worship (and I spent 20+ years on)..the industry is moving on faster than most can wrap their heads on, but for those who understand software engineering was always beyond and above code, they will adapt, meanwhile, those who built their entire identity and skillset around managing code will struggle. There will be a place for those people, but it will be niche and specific, and we won't need as many.