These questions are even not about AI: if I were to give money to a human agency and were given something they tell me works, I would ask the same questions. If I did not know how to evaluate, I would hire people that do. With LLMs the verification part is what bothers me the most.

The only decent software engineering perspective I’ve seen has been from Mitchell Hashimoto.

> I am sure it is not perfect (I only spent an hour working with the results), but a software engineer would iron out the remaining potential bugs that I could not find quickly [...]

People have said things like this many times in the past, and, in the past (perhaps not now), it's always been a misunderstanding of what is good and bad, what's difficult and easy.

For example, someone would draw a UI in a GUI painter that generates code (or a resource file), and a manager would see it and think the majority of the work towards the product is done. (Incidentally, then there seemed to be a reaction, towards making your UI mockups look abstract or otherwise different from runnable code, helping the nontechical to understand that this isn't 90% of the finished product.)

Or a student intern hacks out a homework-grade demo, and a manager who understands neither software engineering nor product domain says "we just need some engineers to polish it up for production", and thinks the student is a star and why can't their engineers be as brilliant and productive. (I might have once been that energetic intern, who was happy for the encouragement, but then learned more, and saw it was a thing.)

This common misunderstanding was sometimes self-correcting -- when trying to ship became a disaster of misery and regretted-attrition, or the product was poorly received by the market because it wasn't thought through nor implemented well, or building subsequent functionality atop it was a nightmare. (But adverse effects of bad approaches is one of the reasons for management and ICs to job-hop, before the unwanted effects affect them personally.)

What might be different now is that some of these AI tools are outputting better-engineered work than some software engineers, and much faster.

At the back of my mind, I'm wondering how the really great software engineers will continue to stand out, as the discipline is being devalued in the minds of most leadership, and anyone can prompt an AI to generate something that superficially appears to them like what they assume a great software engineer would produce. (Even if the great engineer would do much better quality of implementation, have innovative ideas that ML from open source code would not, and maybe arrive at better product concepts as they worked through the problems.)

They can just summon bespoke software out of the ether that only handles the use cases of themselves and a few of their collaborators.

Making “side projects” was mot possible for non-developers before powerful LLMs. Now it is.

Imagine not being an architect and using Claude to put together a building plan, then concluding it’s basically done but we might need a real architect to double check the measurements. It may even be true but I’d be skeptical if it’s always non-architects saying this.

This very well summarizes my current thinking on the subject as well. And most of my career has been playing the role of technical debt nazi. Much to the detriment of my earning potential.

Does AI make incredibly inefficient code most of the time? Yup. But it does it at lightspeed with minimal effort.

I think many software engineers forget they exist to get real things done (in many cases at least) and they are a cost center for most businesses. If your end product is not selling software, very few people actually Doing the Thing(tm) will give a single solitary care about code quality or maintainability when they can just spend 30 minutes and $15 worth of tokens to fix it.

It won't take over everything, but I've already seen otherwise very intelligent go-getter type folks who are not technical or know how to code made extremely useful things for themselves and their small little enterprises. And this will seemingly only get better and more efficient.

For someone who really does love the idea of well architected and future-proof code this is just icky to even say or consider. But I'm coming around to this is the future for the majority of software for most places. And it may have the ability to seriously even the playing field for small enterprises in some industries.

I'm currently using it to implement a zillion side projects at home I've been "meaning to get to" for years. It makes incredibly silly unmaintainable code most of the time - but I learned to not care, and just tell the AI bot to fix it/add to it as I go along. Worst-case I spend a single night deleting it all and starting from zero to "refactor" an entire thing.

I am suprised to hear people so naive they expect their token usage to stay flat if code quality and maintainability starts falling exponentially?

What if to fix 2 bugs your LLM starts adding 50 new ones? Will you tell your customers in supports channel "sorry software is finished, if we try fixing anything, everything else might break, not worth it". Or "we can probably fix it, but our AI usage will raise so much we need to up the subscription 3 fold, you choose".

The speed at which LLM codes is only comparable to the speed at which they add garbage to your repo. If you stop caring about maintainability, you also stops caring about your AI/LLM related bills and the viability of your project past the PoC stage.

Another thing though is selling software in the first place will soon become tough proposition outside of a few niches.

There's no reason to think that quality and maintainability will start falling exponentially. On the contrary, these models get better every couple months, and 99% of software isn't actually that complicated. There's just no reason for the fear-mongering that fixing 2 bugs will cause the LLM to add 50 new ones.

Not 50:1 but it does happen

One billion percent. I think the vast majority of the anti-AI sentiments I hear from software engineers comes down to them caring more about playing with their tools than actually solving the problem.

This hits the nail in the head.

Detractors often hang on to examples of coding assistants making mistakes or output subpar code, but they somehow miss the fact that coding assistants can also be prompted again and refactor whole swaths of code just as fast as they introduce oopsies. This means that the worst case scenario implies fast convergence to an acceptable outcome, and from there also fast iteration to improve upon that.

The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering. Let engineers really own the architecture. Enforce that any new feature - no matter how small - to be specced out with complete sequence diagrams. Ensure that every new software package needs to be put on an UML component diagram for the team to review and see each addition interacts with the whole system, etc.

If we do that, then we can just give all the documents to a coding agent and say "go ahead and implement this" with a minimal amount of confidence. But in doing this, I bet we will realize the following:

    - the "effort" has never been about writing code itself. The code is just the material manifest of all the thought that went to think over a solution into the problems that the product is attempting to solve.

   - we will likely be better off by using code generation tools (i.e, UML-to-code) and a "weak" LLM (than can run locally) than by playing the token lottery at the Anthropic Casino.

I'd substitute "owner" for the team and in that sense the owner will not need to be human.

We're at this state where Claude is great at doing the "middle" part of work, but it's crap at gathering requirements and verification of what it has done. I also don't see people caring about these aspects of software development as shown in the article

That's so far been called software development.

All software developed by people suffers from this issue.

Where exactly is the novelty?

> The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering.

Nonsense. The problem is exactly the same.

With agents iterations are much faster, and this can mean things can get messier faster but can get in shape just as fast.

Ironically, agents improve the quality of the deliverable as well. Approaches such as spec-driven development do a far better job delivering features up to spec than manual coding by flesh and blood developers.

There's an awful lot of baseless scaremongering in your post. You make it sound like with AI assisted coding developers stopped paying any attention to quality.

The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade.

Your LLM, with its higher throughput, may put you in that game breaking situation next week.

And that’s pretty much where you are wrong. Take any long running open source project and you can see the craftsmanship that goes into it. It may not be perfect, but hacks are clearly marked as such.

I’m not saying that you can’t use AI to do it because I believe that with carefully controlled workflows and context management you can, but it’s not a simple prompt away, it’s requires guidance and understanding, and isn’t the speed demon that raw prompting is.

That's not really the point though. That presumes models are only useful if they are one-shot models. That is false.

I mean, what if your prompt successfully changes 20 source files and makes a mess in one? How much work did it saved?

And the elephant in the room is when models actually outperform whatever the prompter is able to deliver, and faster. That is somehow left out.

That’s not at all what I’m saying.

I’m saying that in my experience across multiple models, the follow up prompts don’t fix prior underlying issues. They usually patch on top instead, unless you give them significant and time consuming guidance.

I want them to be more useful outside of one-shot uses, but I find that they currently miss the mark.

That's not my experience at all, and I have been using models that are far from being cutting edge. Even in the cases where a model generates utter nonsense, a couple of clarifying questions is all it takes to get it back on track.

But that might be a factor of the project being worked on, and the extension of the changes being asked.

I think computers are incredibly cheap compared to humans. These models and infrastructure to run them are going to only get more efficient in time. Right now we are still using (for the most part) entire hardware architectures mostly shoehorned from one purpose (graphics) into another. As purpose-built hardware becomes more prevalent and the SOTA starts to slow down I can't imagine a $100k hardware box not being able to handle a small team of developer's needs for many things.

I do think there will be a place for the top 20% of software engineers forever. But most people are not in that top 20%, and the quality when you get below average is not a linear progression. It will not be that difficult for AI generated code to beat the "bottom end" of the industry since tbh it's hard for me to tell the difference between LLM generated code and some of the shit I've seen over the years. I've ran across code written by folks who don't know what an array is more than once.

Most software is not built by MIT and Stanford grads making $500k/yr in the Valley. It's built by work-a-day programmers in the middle of nowhere making $80k/yr to keep some niche small business going with hyper-specific software that was first designed for Windows 95. Or stuff like making horribly designed Wordpress plugins. Or Shopify integrations. etc. etc.

I've also seen these small businesses totally held back by incompetent programmers, and despite their best efforts and huge amounts (for them!) of investment they can never seem to fix it. These types of enterprises are having AI run circles around their current engineering practices, even if it would make most FAANG engineers gasp in horror.

Either way it will certainly be interesting to watch! I just wish I was closer to retirement.

Doesn't matter how fast you can make the wrong thing.

No, you can't. Adjusting prompts ensures absolutely nothing.

My preferred workflow these days is to pair program with an LLM until it gets close-ish and then manually touch it up. Without that, it just produces junk in different forms.

The author specifically says:

> I am sure it is not perfect (I only spent an hour working with the results), but a software engineer would iron out the remaining potential bugs that I could not find quickly (which is one reason we may need more, not less, coders in the future, to help with the explosion of new uses for software)

which acknowledges pretty clearly that engineers bring a level of insight and experience still missing from Mythos. Saying that, I totally disagree with his contention that this will always be true. It's pretty weird that the author of an article stressing the steep improvements in a model's capability can't seem to imagine further improvements in that capability. As if Mythos is where development ends or whatever gap remains between models and experts won't steadily narrow or eventually widen in reverse.

> With Fable the spell has gotten powerful enough that I am no longer sure I am the wizard. I am closer to a patron. I describe what I want, I pay for it, and I judge the result. The conjuring happens somewhere I cannot watch, in hundreds of small choices I never get a vote on. The work has shifted from process to outcome. I no longer steer; I commission.

have a very different meaning coming from a non-technical researcher than they would from someone who builds software for a living.

Apple was Woz's side project, once upon a time. Adsense came from Google's 20% time. Social media started as a side project.

Forests grow from trees. Trees grow from seeds. More potential seeds = more potential forests.

The question was "are side projects a trillion dollar industry" not "has a side project ever started an industry"

How much of a new $1T software product will anthropic capture in token costs, anyway?

But which self-own exactly do you mean, of the many there are?

The trick to getting good at using LLMs for software is to learn how to make _all_ projects low-stakes.

Like, an AI coaching session for executives at the yearly executive retreat. You show up, spend a few hours going through some nonsense slides ChatGPT put together for you, you charge an eye watering fee for it, HR or whoever organizes it will gladly pay for it because it will make them look all cutting edge in front of the CEO, by the next day everyone will forget about it. No accountability at all!

Monoliths vs micro-services.

Unless you know enough to tell them to! And keep them honest about it...

this doesn't really work in the real world. There are many things that actually matter, engineering is fundamentally about handling them.

And at my own firm, I think every developer is generating most of their code using agentic coding. We're still sceptical enough that we are doing the usual heavy handed human review process, so we're not seeing a huge speed up in delivery times, but we are seeing a volume increase. That is because writing the changes and raising the PRs is much faster, but also a lot of boring admin and support work is now mostly done by LLMs. Reports of instability, vague client requests, etc? Throw the LLM at them and it usually figure it out why I continue to engineer.

So I know, first hand, that these things are very good. I also know second and third hand that pretty much every fintech in the industry is as heavily using agentic coding as we are.

And then I come to HN or reddit and I see people telling us that they cannot write decent production code, and this is just wrong. This isn't opinion wrong, it is objectively wrong. Any fintech that wants to keep up will tell you this.

I can't speak for other industries but I can't imagine they're different.

So, I'm not sure what to conclude from this. I don't want to be uncharitable, but when HN/reddit posts just don't match the reality I see for myself, I have no choice but to categorise them as being emotionally driven to stick to a particular narrative, and so I can dismiss them.

What I take from that time also is that the hand loom weavers were not incorrect. The power loom did not do as good of a job as they did by hand.

You can still by a hand woven shirt today at a premium price.

There is a category error as if quality is the product as opposed to one input of the product.

You probably don't get to be a master craftsman without that quality mindset so they aren't wrong but missing the forest for the trees.

Yes, it does nearly all the typing for me now. But left to its own devices, it'll happily spit out awful code.

> I see people telling us that they cannot write decent production code, and this is just wrong.

At least for me, that has never been the counterpoint that I’ve been making. I’ve never cared about code itself, especially with languages like Java and Kotlin, where you basically autocomplete most of the code, and with SDK like ios where you can collect snippets for most of the patterns that you need. And with frameworks like Laravel, where most big additions are done with the tooling. And because code is so repetitive, editors like emacs and vim have lots of features and plugins to help with copying and pasting (registers, macros, navigation, snippets,…)

And the fact is some code you wrote today will be worthless tomorrow and will be replaced and deleted. So, it’s very rare to care about some particular snippets or patch of code.

What myself, and others, have been complaining about is the quality of the codebase and the sustainability of the practice. Especially with the associated claims about increased productivity.

I care about correctness. Simplicity and reduced amount of code increase my confidence that I can achieve it. New features, until tested in production, are more probable to decrease the reliability of the software. And with each fix for a bug, I need to make sure that I’m not adding five more.

To this day, I’ve not seen any compelling arguments that is about writing better code reliably. I’ve seen a lot about writing more code. It’s like manager thinking if you’re not at your computer typing, you’re not working.

> We're still sceptical enough that we are doing the usual heavy handed human review process, so we're not seeing a huge speed up in delivery times, but we are seeing a volume increase

Are you seeing a quality increase? Less customer bugs, less outages, faster resolution? Are you measuring those?

We're not at the stage to measure yet. We may be behind others, not sure. Actually, this isn't quite true. I was interested, so a created an ad-hoc report (with AI) on PRs landed per week over time. This has gone up over the last 6 momths. But that is hard to say why that is. It might just be people are raising smaller PRs because it becomes easy to have the AI split things up, while before, people were too lazy to do this.

Our bottleneck is still that we want humans to review. Sometimes we spot errors, but our pre-existing testing frameworks are very robust already, so if these pass, we're very confident to release to production, and the agent is excellent at understanding the existing testing frameworks and adding to them for new stuff.

So in our team, we don't often see blatant logic errors. It is mostly to do with things like using a pattern that is used elsewhere in the codebase (or not at all) and doesn't belong in our specific section of the code (we have a large monorepo). These become fewer as we enhance our ruleset (AGENTS.md or CLAUDE.md) for our particular developers.

So how can you justify this comment of yours from your reply if you’re not measuring anything? Mind you, I can easily get good results from AI tools, but I don’t like the experience and the code is often over-engineered and drifts away from my target architecture.

But the worst is quickly loosing sight of the tiny technical details that matters when solving bugs or altering features. I don’t like typing code. What I like is to be able to go directly to the code that I need to change, modify it, and then verify that it works. Most of my time is spent deep thinking about the design of the software which is orthogonal to code.

And if there is one thing that is common about people fully onboard with LLM is that they can talk about the product, but they can’t argue about its behavior and its correctness. There’s no intrinsic model that they can compare with the real code. They don’t know the edge cases, the technical pitfalls, how the software will react if you modify one component. Any brainstorming session quickly turns into a slog because they cannot contrast approaches anymore. You can see the decay of understanding in realtime.

I think it is going to continue to get better, and I don't think we'll be having this argument in two years time. Our entire industry will look very different.

I am creating a game and I can say that with the coding part the models help a lot, mostly gpt 5.5 high. Tbh to me all the frontier models feel the same and they can all solve the stuff I do quite well with some guidance and prompting. But that kind of makes me appreciate the other stuff more like visual style, sound design, mechanics etc etc. Tons of work still.

For brainstorming I find the models bad nowadays or maybe I am just too critical of the results

    the quality of produced code and the medium

If the observed behavior of the software is good, then the software is good. If a bug, of whatever kind, can be fixed by a model on a vibe-coded codebase, then that's a fixable bug. If there are no exploitable vulnerabilities, then the code is secure. If the performance is adequate, then the code is performant.

It simply does not matter what the code looks like if, from the outside, it does what its supposed to, and, from the inside, a model can fix the issue if one is found.

More than ever, software engineering is now really a job about making sure the code is doing what its supposed to.

And even if it DOES matter what the code looks like, you can have a model fix that too.

But all of those correctness are imaginary. The hardware only enforce a few (and it may be buggy). The OS adds some more (and it’s buggy). The compiler/interpreter may have bugs (but that’s rarely a nuisance) and the libraries are often brittle. There are cracks everywhere in the tower of abstractions.

The code has never mattered. What has always mattered is the knowledge of what is the model of correctness of the software (programming as a theory by NauR), so that you can discern where a program is wrong.

The thing is a crash or some other immediate errors are actually nice to have. You get to react immediately and can have a core dump or a stacktrace that points you the error. What is truly a terror is silent corruption (wrong order of operations, wrong values for a comparison that has expanded the idea of correctness, security issues that has been backdoored for years,…).

As Hoare said:

  There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
  The first method is far more difficult.

That is so real. Brilliant !

I clicked one of his examples intrigued "a snake game where the snake is self-aware and crazy things happen;". Played for 1-2 minutes, and it's the classic 1980s snake game. Am I missing something? What is "self-aware" about it? Some funny messages at the bottom of the screen? And what are the "crazy things"?

I will say, the act of eating creates a "bulge distortion" that flows down the length of the snake is a nice touch though.

The lack of downvotes on posts on HN has always felt like more of a bug than a feature to me.

Everyone does. You don’t think about it everyday because we’ve delegated it to experts which don’t come up with a new composition of Asphalt every time you press “generate”. It’s rigorously battle tested and short of intentional negligence, it’s consistent. I’m amazed how people are forgetting how the world actually works.

If AIs can generate code that looks ridiculous to humans but over time has the correct performance, the correct behaviour, no-one outside of software engineers will know or care.

They do those in labs, and then studies are made to prove that it can replace the current composition. They do not invent those on the spot and let the drivers QA the road.

> If AIs can generate code that looks ridiculous to humans but over time has the correct performance, the correct behaviour

It’s on you to prove that this big “if” can be realized. A -> B only matters when A is true.

Not really. This is a discussion about what code looks like if AI can write applications that are as good, stable, correct as humans.

I think they can, better than most programmers at the moment, with the correct guardrails and supervision. But in time, I think we may not need to review the code at all, but instead verify correctness and performance only. The AI can write the code however it likes.

Obviously I don't have a proof for this, but based on the progress I've seen so far, if someone forced me to bet one way or the other, this is what I'd bet on.

But yes, you are right - I don't build roads and don't know what is a price to build a road and how to determine the quality of correctly built one, nor I will ever care or learn.

That's not how I am reading it. You will get a road built exactly to your spec, quickly. So no penguin crossings unless you ask for them.

I am also not entirely sure how the pothole argument translates.

In fact, that's the entire reason we care about "quality code", because we assume that quality code is code that does what you expect well and consistently.

I say this as someone who hand writes code pretty much every night for fun, just to experiment with computation. Which, oddly, is more fun than ever because I don't feel like there's any need to connect this type of programming with "real world software", and I can really enjoy code for it's own sake, meanwhile my job is mostly just running agent loops (which I quite like as well).

That is the entire purpose of "quality of code".

If the end user experiences a correctly performing application, now, and in the future, they don't care at all what the code looks like.

AIs could resort to a single global array of primitives and forget all about functions, and just use gotos if it helped them (it probably doesn't).

I get that there's little sense in arguing with the MBA hivemind, but... c'mon.

I manage two teams of highly motivated, largely pro-AI engineers. Both teams have independently concluded that they needed to ramp down GenAI usage because of code quality / maintainability concerns. Both teams have suffered from protracted outages caused by LLM jank not being sufficiently fenced off and guarded against. Both teams have expressed concern that the code generated by LLMs is far too verbose, full of slop, and rapidly becomes an unmaintainable mess.

These are teams that are building non-trivial LLM solutions (deep agentic data synthesis and multi-modal data tagging). They are using the technology creatively and pro-actively, not just vibe-coding slop and throwing their hands up when it fails. Both teams will continue using GenAI coding agents, don't get me wrong - but the gains are incremental, not transformative, and need careful fencing to make sustainable.

Nothing in these articles resonates as real. People who work in reality don't agree. I don't understand why this shit keeps getting attention (or rather I do, but the reasons aren't good).

I said I had zero concern for the quality of the code. That is, I do not have concern that the quality of the code will be a concern in and of itself.

It's a subtle, but IMO important difference. We only care about code quality so as it gives us stable, understandable systems. Historically that meant a human had to read and understand it. Suppose a future where that's no longer the case, then we may still end up with stable, understandable systems without understanding every minutiae of the substrate. It's the same way I don't really know if my compiler is correct, but the behavioral patterns of my code suggest it is without me understanding anything about its code quality.

Also this is easily solved by .md spec files, this whole "bad code" cope is just FUD'

Why are you allowing AI rockstar managers to (I assume) push without code review? Why are you cleaning up the fallout? It's not AI issue, it's people issue

My manager got the mandate she needs to start coding, she doesn't want that, no one in our team wants that, she's a great manager exactly where she is right now. Nonetheless, we are helping her to code to show something for the higher-ups so she can keep her job, we really don't want to lose one of our best managers because some C-level is anxious about AI...

- show increase in errors and outages caused by this approach

- integrate manager changes into your CI pipeline (coding / reviewing / testing / documentation)

- discuss how your manager can do the changes they need to do without sidetracking all other work

Make it indeed about the money: coding by PM + fixing what was coded + dealing with fallout is greater expense than coding by PM + automated guidelines + reviewing what was coded.

That is - if the environment you're working in is reasonable and it's not a power play by your PM

On your points:

Manager changes are always going to go through the usual pipeline, we are 10k+ people so there's not even a way to go all gung-ho pushing stuff. They need to be reviewed, approved, etc.

But we don't want our manager to code, nor does our manager, so we are just helping to cross the bare minimum expected from higher ups. For my team it's not an issue with our manager's code (those will be at max small fixes, well-defined, the most trivial stuff), the issue is they are mandating managers to do it.

I don't know what size of company you work at, where I am at there is simply no incentive for me to do all the extra work to show execs/higher management the issues cropping up.

I don't even have access to them, I have to pass through other channels, those might compile reports from many people to try to present a case, if they get to present a case then there's a whole other discussion to happen at director/VP/C-level about what they want to do, and since it goes against their big mandate it most likely will just be thrown out.

In this structure I have no motivation at all to go out of my way to perform data gathering/analysis, wrapping it all in a nice concise document explaining what the data means, potential remediation, etc. just to become a footnote in someone else's document that ultimately will not change anything from the VP/C-level mandate.

Same as it ever was.

The only difference now is that if you let it happen, it'll happen 100x as fast.

When I was mentoring junior devs, I would start by fully reviewing their code. If they had a ton of mistakes more than a few times, I would only review until the first mistake, and then reject it. Repeat, repeat, repeat, until they got the picture that I wasn't going to let mistakes through, and handing me a ton of mistakes was going to waste more of their time than mine.

I let the pain be their pain, instead of mine.

But good developers, I'd help them by doing a more thorough review and not wasting their time. Good developers were the ones that made an honest effort to follow the requirements to the letter and test their own work.

We further emphasized this by having a very simple coding test during the interview, and the only thing we cared about was whether they followed the requirements to the letter. There wasn't a lot left to the imagination, and the requirements were very clear. Anyone who missed them wasn't someone who would do well with us.

That very same test will help filter out a lot of AI-braindead candidates that don't check the AI's work as well.

Actually, I wish I still had the exact test so I could throw it against an AI and see what happens. I'm a little afraid that it would pass it too easily now. I'm not sure how I'd fix it to prevent them from just using AI.

Domain expert can develop working code, but they will not be able to ensure above.

Still Claude will sneak things in - in my recent plan, for example I had defined, per acceptance criteria what colours the statuses should be: green for live, blue for sold, grey for anything else; it changed this to: green for live, orange for in progress, blue for sold, red in demolition, etc. When pressed why did it to this, it was unable to explain why. This is with a plan where AC were explicitly provided from the task in Given/When/Then format and were to be adhered to strictly. I've caught this within planning, but I shouldn't need to be doing this.

Even in standard prompts where I tell it "Change this label from X to Y", it ended reordering the tabs unrelated to ask. Again I was not able for it to explain why - it was so abrupt. And it was in fresh context, without any pollution on what I expect it to do.

I also noticed a different behaviour regarding skill; today and yesterday it would not be following skill guidance at all ie: skill writing skill - I'd have to explicitly tell it to test skills after writing them, when this is a behaviour expected by default. Similarly with other skills - knowing that it should have done something per skill guidelines and it not doing it at all. This is new behaviour that I've not seen a week ago.

Webdev here, but currently I have: - a skill where I outlined how the architecture of the system should look like, with guards (static analysis, architecture tests, linting) confirming that the code it generates adheres to standards

- a skill that tells it how tests should look like (use generators, write both feature / unit tests)

- a skill that tells it to generate docs from the code in a form of acceptance criteria (Given / When / Then)

- a skill that tells it to generate frontend uat tests + accompanying backend seeders given the AC

- a skill that tells it to verify that ticket objectives match what was delivered

At this point I still need to guide it to move task from one stage to the other (coding, testing, verification that indeed what was coded adheres to what was required), but I believe that these dynamic workflows can automate this work as well.

Is it, though? If all you want is a movie, you can make it for both less money and less time. And if you actually have some modicum of talent, you can make it higher-quality to boot; see Joel Haver, who challenged himself to author, film, edit, and release 12 feature-length films during the course of 2024 on effectively no budget whatsoever (playlist here: https://www.youtube.com/watch?v=C-ZRRTsa5SY&list=PLKtIcOP0Wv... ).

edit: looking at others, Pi - 4w and $130k

The cube was not “done” in 3 weeks. Maybe they shot it in 3 weeks, but there were years of pre-production, and at least months of post-production. (According to wikipedia.)

Saying that it was done in 3 weeks is like saying that windows 11 was done in 45 minutes, because that is how long the compilation lasted.

> with budget of $350,000 CAD

“50% of the budget as C$350,000 to C$375,000 in cash and the other 50% as donated services, for a total of C$700,000. Natali considered the cash figure to be deceptive, because they deferred payment on goods and services, and got the special effects at no cost.”

Direct quote from wikipedia.

Last year many developers were saying that it produces slop and so-on which is genuinely annoying when we know it's months/years to be GUARANTEED to be solved, as theory already proves we can go way further with models (theory means practice eventually), so we must not talk about "now" as in 1 week near but what it will be, as if it's already there imo. Even more annoying about the image gen AI, it's OBVIOUS that it will reach perfect accuracy (at least for human eye), as if we will just throw TRILLIONS of investment by the window and just stop here, nope, this will reach camera level, runtime, instantly rendered.

Else for the job loss, it's like the moment we realize that it can automate 99% of white collar jobs, we would suddenly be surprised when Opus 10 can do it? We shouldn't, we KNOW there will be Opus 10 that reach 99.9% in all benchmarks, like we know we will have Opus equivalent models running on our phones.

I won't be surprised when I see Opus 4.8 equivalent performance running on a 10B model, as this is just logical, I start to kinda hate it that we all act "surprised" with new models every few months as if the science behind it all changed suddenly, no... we just start developing what science is backing up already.

So obviously, music, video, writing... will be produced at a much higher level than humans, soon enough, there is no ceiling with AIs, humans are pretty limited.