[flagged]
Eight years of wanting, three months of building with AI
331–340 of 349 posts
Re: Eight years of wanting, three months of building with AI
#332> Tests created a similar false comfort. Having 500+ tests felt reassuring, and AI made it easy to generate more. But neither humans nor AI are creative enough to foresee every edge case you’ll hit in the future; there are several times in the vibe-coding phase where I’d come up with a test case and realise the design of some component was completely wrong and needed to be totally reworked. This was a significant con…
Use tla+ and have it go back and forth with you to spec out your system behavior then iterate on it trying to link the tla+ spec with the actual code implementing it Pull out as many pure functions as possible and exhaustively test the input and output mappings.
The problem with specs for me is always with boundaries. How many specs do you have for a complex project? How do they reference each other? What happens when requirements cross boundaries?
And finally, how do you address spec drift?
Re: Eight years of wanting, three months of building with AI
#333Earlier quoted context omitted.
> LLMs have only been reasonably good for a few months (since circa Nov'25). Ironically this itself is one of the hyper/doomer takes.
But is it a hyper or a doomer take? There seems to be a concencus among people I follow/read, that somewhere around that time was an inflexion point in coding LLMs, and this matches my personal experience. (My comment was in the context of LLMs being used to generate non-throwaway code, not general GenAI use - apologies if that was unclear.)
> There seems to be a concencus among people I follow/read, that somewhere around that time was an inflexion point in coding LLMs, and this matches my personal experience.
LLMs have been a very useful tool to generate non-throwaway code for at least 2 years. It's a question of Overton Window, of mainstream acceptance, that has made you and the people you're talking about come to a "consensus" that there was an agentic LLM coding step change around that time. There was indeed an inflection point, but it was a social one: a window shift, where it became socially acceptable among mainstream SWEs to hold this sentiment. It had already been the case for a long time, but for those who understood this, expressing that was still not deemed acceptable. Doing so would brand one as a hyper, at least in the particular circles you were in.
You were in reality part of the doomers, just as much as the current doomers are still doomers.
Re: Eight years of wanting, three months of building with AI
#334It's a huge mistake to start building with Claude without mapping out a project in detail first, by hand. I built a pretty complex device orchestration server + agent recently, and before I set Claude to actually coding I had ~3000 lines of detailed design specs across 7 files that laid out how and what each part of the application would do. I didn't have to review the code for understanding what Claude did, I review…
> It's a huge mistake to start building with Claude without mapping out a project in detail first, by hand. I agree with you in theory but in my opinion, it doesn't work so well when you don't even know what exactly you are looking for at the start. Yes I knew I wanted a formatter, linter, parse but which language should those be written in, should they be one project or many, how the pieces should fit together, none…
> in these sort of "greenfield projects" I work a lot better with concrete prototypes and code in front of me I can dissect instead of trying to endlessly play with designs in my head
I'd really recommend separating prototyping work like that out into a pre-design phase. Do the prototypes and figure out the direction for the actual project, but then come back in with a clean repo and design docs built off the prototypes, for claude to work from. I started out using claude to refactor my old projects (or even my codex ones) before I realized it worked better starting fresh.
I think sometimes it silently decides that certain pieces of code or design are absolute constraints, and won't actually remove or change them unless you explicitly tell it to. Usually I run into this towards the end of implementation, when I'll see something I don't expect to and have to tell it to rip it out.
One example recently was an entire messaging queue (nats jetstream) docker image definition that was sitting in the deploy files unused, but claude didn't ever mention or care about it as it worked on those files; it just silently left it sitting there.
Another example was an auth-bypass setting I built in for local testing during prototyping, being not just left alone by Claude but actually propagated into other areas of the application (e.g. API) without asking.
Re: Eight years of wanting, three months of building with AI
#335Earlier quoted context omitted.
I can't agree here. https://pelorus-nav.com/ (one of my side projects) is 95-98% written by Claude Opus 4.6, all in very nice typescript which I carefully review and correct, and use good prompting and context hygiene to ensure it doesn't take shortcuts. It's taken a month or so but so worth it. And my packing list app packzen.org is also pretty decent typescript all through.
> which I carefully review and correct So you do agree? If you are having to review and correct then it's not really the LLM writing it anymore. I have little doubt that you can write good Typescript, but that's not what I said. I said LLMs cannot write good Typescript and it seems you agree given your purported actions towards it. Which is quite unlike some other languages where LLMs write good code all the time — n…
I find correction is rarely necessary with Opus 4.6. Definitely not so much that "it's not really the LLM writing it anymore." More like it's the author and I'm the editor (in this limited case -- of course architecturally the ideas are all mine.)
But I totally respect that my prompt style, the type of app I'm writing, and other factors could be influencing my success vs. others' lack of success.
Re: Eight years of wanting, three months of building with AI
#336Refreshing to see an honest and balanced take on AI coding. This is what real AI-assisted coding looks like once you get past the initial wow factor of having the AI write code that executes and does what you asked. This experience is familiar to every serious software engineer who has used AI code gen and then reviewed the output: > But when I reviewed the codebase in detail in late January, the downside was obvious…
+1 I’ve been driving Claude as my primary coding interface the last three months at my job. Other than a different domain, I feel like I could have written this exact article. The project I’m on started as a vibe-coded prototype that quickly got promoted to a production service we sell. I’ve had to build the mental model after the fact, while refactoring and ripping out large chunks of nonsense or dead code. But the…
> On Friday...
This should be done on day one with a company-wide skill or project template that defines hard limits and processes for the Agent.
Strict linters, formatters and code quality checks are essential to de-slopify the code as much as possible.
That doesn't fix bad design though, that's still on humans.
Re: Eight years of wanting, three months of building with AI
#337AI coding gives you mass. You still need to provide direction. Mass without direction is just a mess that runs.
Re: Eight years of wanting, three months of building with AI
#338Earlier quoted context omitted.
More and more software will be built by non-experts, software that has smaller user bases and simpler use cases and doesn't need to be maintained as much if at all. "Poor AI code quality" matters much less for these than for say, software written by developers at FAANG companies, since literally nobody will ever even look at the code. Where we're headed is toward a world where a ton of software is ephemeral , apps li…
Ephemeral in the same way the electrical wiring in an old house is ephemeral. Which is to say, not at all. Original wiring done by a professional, later changes by “vibe electrician” homeowners. Every circuit might be a custom job, but they all accumulate into something a SWE calls “technical debt”. Don’t like how the toaster and the microwave are on the same circuit even though they are in different parts of the kit…
Ephemeral like a table quickly hacked together for a specific purpose.
It can hold a single flower pot, will fall over if a kid tries to climb on it, is made from wood that's delicious to dogs and most likely won't last 25 years because it wasn't finished properly.
But the person who made it needed a table for a flower pot, doesn't have kids or pets and will happily build a new one in 10 years when the old one breaks down from bad joins.
Not every piece of shitty software has a massive attack surface the will immediately kill people if it operates wrong.
Is my personal cheap imitation of Hazel[0] I vibe-coded in two evenings perfectly bug free and does it replicate every feature of Hazel perfectly? Of course not, but it does the exact 5 things I need it to do and saved be the upgrade price to Hazel 6.
Re: Eight years of wanting, three months of building with AI
#339Earlier quoted context omitted.
Ephemeral in the same way the electrical wiring in an old house is ephemeral. Which is to say, not at all. Original wiring done by a professional, later changes by “vibe electrician” homeowners. Every circuit might be a custom job, but they all accumulate into something a SWE calls “technical debt”. Don’t like how the toaster and the microwave are on the same circuit even though they are in different parts of the kit…
No ephemeral as in: I'll ask the AI to check my email, and it'll create a bespoke table UI on the fly right inside my AI assistant, and populate it with relevant email data. And I'll use it, and then it will disappear. Software created and destroyed in a moment. Not all software is meant to be some permanent building block upon which other software sits. When new technology arrives that makes earlier ways of doing th…
And a smart agent will eventually notice that it's doing that single operation 5 times a day and creates a more permanent skill/tool for itself instead of reinventing the wheel every time.
Re: Eight years of wanting, three months of building with AI
#340Earlier quoted context omitted.
I didn't say that you "want" spaghetti code or that spaghetti code is good. I said that (a) apps are getting simpler and smaller in scope and so their code quality matters less, and (b) AI is getting better at writing good code.
Apps are getting bigger and more ambitious in scope as developers try to take advantage of any boost in production LLMs provide them.
Yes, some people are pushing everything-apps.
But just as many are creating One More Habit Tracker or Todo App, so many that Apple had to change their review guidelines to block the surge of low-tier app slop.
Internally people are creating bespoke tools for themselves to fix issues in their daily workflows that would've either been a 100k€ software project that lasts for 6 months or required an expensive SaaS system with 420 extra features they didn't need - and the price to match.