That said, this tech will in no way give you anything remotely finished. It will at best be the beginning of a prototype which will require a lot of work to even have a proof of concept.

This is the same as with GenAI for images and video. Simply prompting doesn't get you much. You have to know how to use the tool to achieve a creative vision, and you need the vision to begin with. This idea that everyone will have a vision is vastly overestimated. Most people just want to consume and get entertained... and this is just like with anything else, most people don't want to grow their own food, or build their own house.

I like AI but actually not for coding because code quality is correlated to how well you understand the underlying systems you're building on, and AI is not really reasoning on this level at all. It's clearly synthesizing training data and it's useful in limited ways.

One observation so far is seeing that there is real effort in configuring the agentic workflow, and getting that to work even semi-consistently, meaning that there is always tweaking and experimentation for the specific use case. This isn't trivial work, and arguably it's a tradeoff, since all that effort could be spend coding the game directly. With enough skills it would be about the same time except better quality to code it by hand (with of course AI assistance where needed, but it would be human written).

This just means that the real value so far with AI is in letting non-programmers do coding, but it doesn't come without the cost of real effort to set things up and less quality in the end.

From my experience it's better at some domains than others, and also better at certain kinds of app types. It's not nearly as universal as it's being made out to be.

Anyone who claims AI is great is not building a large or complex enough app, and when it works for their small project, they extrapolate to all possibilities. So because their example was generated from a prompt, it's incorrectly assumed that any prompt will also work. That doesn't necessarily follow.

The reality is that programming is widely underestimated. The perception is that it's just syntax on a text file, but it's really more like a giant abstract machine with moving parts. If you don't see the giant machine with moving parts, chances are you are not going to build good software. For AI to do this, it would require strong reasoning capabilities, that lets it derive logical structures, along with long term planning and simulation of this abstract machine. I predict that if AI can do this then it will be able to do every single other job, including physical jobs as it would be able to reason within a robotic body in the physical world.

To summarize, people are underestimating programming, using their simple projects to incorrectly extrapolate to any possible prompt, and missing the hard part of programming which involves building abstract machines that work on first principles and mathematical logic.

I suspect this is also related to agency, and why we need to spell things out in the prompt and run multiple agents in a loop, not to mention the MoE and CoT, all of which would not be needed if the model could sustain a single prompt until it is finished, creating its own subgoals and reevaluating accordingly. Agency requires creativity and right now that's the human part, whether it's judging the output or orchestration of models.

So far AI has shown it cannot understand this layer of software. There are studies of how LLMs derive their answers to technical questions and it is not based on the first principals or logical reasoning, but rather sparse representations derived from training data. As a result it could answer extremely difficult questions that are well represented in the training data but fail miserably on the simplest kinds of questions, i.e. some simple addition of ten digits.

This is what the article is talking about with small teams with new projects being more productive. Chances are these small teams have small enough problems and also have a lot more flexibility to produce software that is experimental and doesn't work that well.

I am also not surprised the hype exists. The software industry does not value software design, and instead optimize their codebases so they can scale by adding an army of coders that produce a ton of duplicate logic and unnecessary complexity. This goes hand-in-hand with how LLMs work, so the transition is seamless.

Using Velocity Verlet Integration for particle physics. Calculating the Boltzmann entropy based on hot and cold particle count (not sure if this is correct, but will revisit).

Stack: C++ Cmake Raylib

Source: https://github.com/proc0/Maxwells-Demon

Comments URL: https://news.ycombinator.com/item?id=46555668

Points: 2

# Comments: 0

In essence, estimates are useless. There should only be deadlines and the confidence of engineers of achieving the deadline. To the extent there are estimates, it should be an external observation on the part of PMs and POs based not only on the past but also on knowledge of how each team member performs. This of course only works if engineers are ONLY focusing on technical tasks, not creating tickets or doing planning. The main point of failure in an abstract sense is making people estimate or analyze their own work, which comes with a bias. This bias needs to be eliminated and at the same time you give engineers the opportunity to optimize their workflows and maximize their output.

TLDR, engineers should only focus on strictly technical because it allows to optimize within the domain, meanwhile other roles (whoever PM, PO or other) should be creating tasks, and estimating. Of course this doesn't work because there are hard biases in the industry they are hard to break.