491–500 of 522 posts
Earlier quoted context omitted.
The macOS presentation app is at https://github.com/simonw/present
It's kind of underwhelming no? Just a wrapper for a webview.
Earlier quoted context omitted.
I've found that using LLMs has had a very material effect on my productivity as a software developer. I write about them to help other people understand how I'm getting such great results and that this is a learnable skill that they can pick up. I know about the METR paper that says people over-estimate the productivity gains. Taking that into account, I am still 100% certain that the productivity gains I'm seeing ar…
That's beside my point. You are trading off the LoC for quality of code. You're not onto some big secret here - I've also built complete fullstack web applications with LLMs, complete with ORM data models and payment integrations. With the issue being....the LLMs will often produce the laziest code possible, such as putting the stripe secret directly into the frontend for anyone with two neurons in their brain to see…
> Again you are not sitting on a big secret that the rest of us have yet to find out. "Knocking out" an application with an LLM most of us have done several times over the last few years, most of them not being toy examples like yours.
That's still a very tiny portion of the software developer population. I know that because I talk to people - there is a desperate need for grounded, hype-free guidance to help the rest of our industry navigate this stuff and that's what I intend to provide.
The hardest part is exactly what you're describing here: figuring out how to get great results despite the models often using outdated libraries, writing lazy code, leaking API tokens, messing up details etc.
Earlier quoted context omitted.
Unless the specification is also free of bugs and side effects, there is no guarantee that a rewrite would have fewer bugs. Plenty of rewrites out there prove that point.
Yes, but that's the point. We're not writing code in a computer language any more, we're writing specs in structured English of sufficient clarity that they can be generated from. The debugging would be on the specs.
What does "sufficient clarity" mean? And is it english expressive enough and free of ambiguities? And who is going to review this process, another LLM, with the same biases and shortcomings?
I code for a living, and so far I'm OK with using LLMs to aid in my day to day job. But I wouldn't trust any LLM to produce code of sufficient quality that I would be comfortable deploying it in production without human review and supervision. And most definitely wouldn't task a LLM to just go and rewrite large parts of a product because of a change of specs.
Not sure if “code has always been expensive” is the right framing. Typing out a few hundred lines of code was never the real bottleneck. What was expensive was everything around it: making it correct, making it maintainable (often underestimated), coordinating across teams and supporting it long term. You can also overshoot: Testing every possible path, validating across every platform, or routing every change throug…
It's now so easy to generate, that, almost no matter what you do, there is nothing special or secret about it anymore. Especially when you already host at GitHub or Azure or whatever, it's already inside AI.( Even if you don't, they still get their fingers on it)
I know, because I created an AI help chat bot with a help document and API from a closed source product, made it public and then got accused feeding the AI the source code and needed to take it down.
Nope, it was already inside. The documents and help files etc. got the AI to print out part of the source code lmao.
Earlier quoted context omitted.
Will you be updating the text at https://simonwillison.net/guides/agentic-engineering-pattern... ? As it currently says: > A significant risk with coding agents is that they might write code that doesn't work, or build code that is unnecessary and never gets used, or both. > Test-first development helps protect against both of these common mistakes, and also ensures a robust automated test suite that protects against…
I'll be replacing the examples with ones that better illustrate the technique. I dashed off those off in a hurry using the wrong tools (I used ChatGPT and Claude directly, not the Coding agent harnesses Claude Code and Codex) and that was a mistake.
From what I gather, a lot of people are using these code assistance tools because they too are in a hurry, under pressure from management forcing them to go faster with AI, and with limited ability to push back.
You have significantly more experience than most of your readership. Will you be providing guidelines about which tools to avoid for which problems, based on your experience?
Will you use this or something similar as an example of the negative consequence of being in a hurry, hopefully leading to a worked-out example of one might better audit or inspect tool-generated code, and the effort involved?
That would be invaluable for people dealing with overly-optimistic management pressure.
My personal belief is that one of the reasons for TDD's success is as a way for programmers to respond to ill-advised pressure to skimp on testing found in some test-after shops.
That disappears if managers believe instructing an agentic code generator to "use Red/Green TDD" easily ensures a robust automated test suite.
My apologies if you have already done this. I have not followed your work. My interest in this thread is from my views of TDD as a development approach, and the difficulty in generating a test suite which is robust, minimal, understandable, and maintainable.
Earlier quoted context omitted.
I'll be replacing the examples with ones that better illustrate the technique. I dashed off those off in a hurry using the wrong tools (I used ChatGPT and Claude directly, not the Coding agent harnesses Claude Code and Codex) and that was a mistake.
You didn't think they were the wrong tools when you wrote it. You said "this example is simple enough that both Claude and ChatGPT can implement it using their default code environments". From what I gather, a lot of people are using these code assistance tools because they too are in a hurry, under pressure from management forcing them to go faster with AI, and with limited ability to push back. You have significant…
They didn't implement it well enough for people not to pick them apart though, which is a distraction from the concept I'm trying to demonstrate.
This is honestly the biggest challenge in writing about this stuff, especially if you're doing it in public. Any example is an opportunity for people to find flaws which they might use to undermine the larger point I'm trying to communicate.
I have a visible changelog on each chapter now so people can follow how I evolve them over time. I'll try to find the right balance in terms of illustrative examples. My first attempt at linking directly to the first working transcripts I got clearly isn't it.
Earlier quoted context omitted.
Splitting your code up into multiple functions across multiple files is computer unfriendly code. It'll cause L1, L2 and L3 cache misses. Yet it's heailed as very human friendly and maintainable by Uncle Bob and his disciples. As far as code reviews go, do you have any form of evidence that it's not a pseudo science? If I look at our industry today, it's not like it's in better shape compared to where it was decades…
> Splitting your code up into multiple functions across multiple files is computer unfriendly code. It'll cause L1, L2 and L3 cache misses I think you have no idea what you're talking about and trying to sound technical based on some concepts you misheard somewhere. A lot of non-tech people got into "tech" in the last years not because they were passionate about technology but because they heard they could make more…