Also…

  def _save_current_date_time(current_date_time_file: str, current_date_time: str) -> None:
    with Path(current_date_time_file).open("w") as f:
      f.write(current_date_time)

The scary thing is: I have seen professional human developers write worse code.

They’re very good at honing bad code into good code with good feedback. And when you can describe good code faster than you can write it - for instance it uses a library you’re not intimately familiar with - this kind of coding can be enormously productive.

Note how it has invented the faster parameter for the zpool command. It is possible that the blog writer hallucinated a faster parameter themselves without needing a LLM - who knows.

I think all developers should add a faster parameter to all commands to make them run faster. Perhaps a LLM could create the faster code.

I predict an increase of man page reading, and better quality documentation at authoritative sources. We will also improve our skills at finding auth sources of docs. My uBlacklist is getting quite long.

  def ensure_dir_exists(path: str) -> None:
    """
    Ensure a directory exists.

    Args:
        path: Directory path
    """

    # Ensure the directory exists and is writable
    ensure_dir_exists(work_dir)

    work_path = Path(work_dir)
    if not work_path.exists() or not os.access(work_dir, os.W_OK):

This might not matter here because it's a small, trivial example, but if you have 10, 50, 100, 500 developers working on a codebase, and they're all thoughtlessly slinging code like this in, you're going to have a dumpster fire soon enough.

I honestly think "vibe coding" is the best use case for AI coding, because at least then you're fully aware the code is throwaway shit and don't pretend otherwise.

edit: and actually looking deeper, `ensure_dir_exists` actually makes the directory, except it's already been made before the function is called so... sigh. Code reviews are going to be pretty tedious in the coming years, aren't they?

Worse by far is still the ability of AI to really integrate different problems and combine them into a solution. And it also seems to depend on the language. In my opinion especially Python and JS results are often very mixxed while other languages with presumably a smaller training set might even fare better. JS seems often fine with asynchronous operation like that file check however.

Perhaps really vetting a training set would improve AIs, but it would be quite work intensive to build something like that. That would require a lot of senior devs, which is hard to come by. And then they need to agree on code quality, which might be impossible.

Saying that, for typed languages like TypeScript and C#, they have gotten very good. I suspect this might be related to the semantic information can be found in typed languages, and hard to follow unstructured blobs like dataframes, and there for, not well repeated by LLMs.

Explain the issue with load_json to me more. From my reading it checks if the file exists, then raises an error if it does not. How is that carrying on as if the file is certainly there?

> However, my broad understanding of software architecture, engineering best practices, system operations, and what makes for excellent software projects made this development process remarkably smooth.

If the seniors are going to write this sort of Python code and then talk about how knowledge and experience made it smooth or whatever, might as well hire a junior and let them learn through trials and tribulations.

I asked $random_llm to give me code to recursively scan a directory and give me a list of file names relative to the top directory scanned and their sizes.

It gave me working code. On my test data directory it needed ... 6.8 seconds.

After 5 min of eliminating obvious inefficiencies the new code needed ... 1.4 seconds. And i didn't even read the docs for the used functions yet, just changed what seemed to generate too many filesystem calls for each file.

But the alternative would be the tool doesn't get built because the author doesn't know enough Python to even produce crappy code, or doesn't have the money to hire an awesome Python coder to do that for them.

While I would have hoped for a better result, I'm not surprised. In this particular case, I really didn't care about the code at all; I cared about the end result at runtime, that is, can I create a working, stable solution that solves my problem, in a tech stack I'm not familiar with?

(While still taking care of well-structured requirements and guard rails — not to guarantee a specific level of code quality per se, but to ensure that the AI works towards my goals without the need to intervene as much as possible).

I will spin up another session where I ask it to improve the implementation, and report back.

It's not a race. It's just redundant. If the file does not exist at the time you actually try to access it you get the same error with slightly better error message.

By the way, prompting models properly helps a lot for generating good code. They get lazy if you don't explicitly ask for well-written code (or put that in the system prompt).

It also helps immensely to have two contexts, one that generates the code and one that reviews it (and has a different system prompt).

https://github.com/dx-tooling/platform-problem-monitoring-co...

Where things are placed in the project seems rather ad hoc too. Put everything in the same place kind of architecture. A better strategy might be to separate out the I and the O of IO. Maybe someone wants SMS or group chat notifications later on, instead of shifting the numbers in filenames step11_ onwards one could then add a directory in the O part and hook it into an actual application core.

It's been depressing to listen to people pretend that LLM generated code is "the same thing". To trivialize the thoughtful lessons one has learned honing their craft. It's the same reason the Studio Ghilbi AI image trend gives me the ick.

It also lets me explore other libraries and languages without having to invest too much time and effort before knowing if it's right for what I want to do. I know that if I want to continue in a different direction, I haven't wasted tons of time/effort and getting started in the new direction will be much less effortful and time consuming.

On the other hand, most tasks aren't fun nor satisfying and frankly they are a waste of time, like realizing you're about to spend the afternoon recredentializing in some aspect of Webpack/Gradle/BouncyCastle/Next.js/Combine/x/y/z just to solve one minor issue. And it's pure bliss when the LLM knows the solution.

I think the best antidote to the upset in your comment is to build bigger and more difficult things. Save your expertise for the stuff that could actually use your expertise rather than getting stuck wasting it on pure time burn like we had to in the past.

I'm pragmatic and simply don't trust current LLM's to do much in my domain. All that tribal knowledge is kept under lock and key at studios, so good luck scraping the net to find more than the very basic samples of how to do something. I've spent well over a decade doing that myself; the advanced (and even a lot of intermediate) information is slim and mostly behind paywalls or books.

I skimmed the vibecoding subreddits for a while. It was common to see frustrations about how coding tools (Cursor, Copilot, etc) were great last month but terrible now. The pattern repeats every month, though. When you look closer it’s usually people who were thrilled when their projects were small but are now frustrated when they’re bigger.

On Greenfield projects there's simply too many options for it to pursue. It will take one approach in one place then switch to another.

On a brownfield project, you can give it some reference code and tell it about places to look for patterns and it will understand them.

Bolting AI onto existing products probably doesn't make sense. AI is going to produce an entirely new set of products with AI-first creation modalities.

You don't need AI in Photoshop / Gimp / Krita to manipulate images. You need a brand new AI-first creation tool that uses your mouse inputs like magic to create images. Image creation looks nothing like it did in the past.

You don't need Figma to design a webpage. You need an AI-first tool that creates the output - Lovable, V0, etc. are becoming that.

You don't need AI in your IDE. Your IDE needs to be built around AI. And perhaps eventually even programming languages and libraries themselves need AI annotations or ASTs.

You don't need AI in Docs / Gmail / Sheets. You're going to be creating documents from scratch (maybe pasting things in). "My presentation has these ideas, figures, and facts" is much different than creating and editing the structure from scratch.

There is so much new stuff to build, and the old tools are all going to die.

I'd be shocked if anyone is using Gimp, Blender, Photoshop, Premiere, PowerPoint, etc. in ten years. These are all going to be reinvented. The only way these products themselves survive is if they undergo tectonic shifts in development and an eventual complete rewrite.

Is that because the Rust compiler is just a very strong guardrail? Sounds like it could work well for Swift too. If only xcodebuild were less of a pain for big projects.

the low-hanging fruit is to create content/apps to help developers create their personal brands through content/apps.