[a_c]

I spent multiple 5-hour sessions spec-ing my climbing app with AI, clarifying interactions, algorithm, workflow etc. It ended up a frankenstein that I didn't recognise or know how each part interact with each other. Command line were a mess, different commands doing the same thing, with similar but redundant arguments. Everything looks kind of doing what I intended but overly convoluted and nothing really works. Real progress was made when I actually dig into the documentation of colmap/OpenMVS (essential tools, which I had never used before, in my workflow).

The AI gave me unprecedented turn around time in experimentation. The same experiments would easily take me over a month in the past. Now it was a few days. But still, real progress is made only when my understanding catch up with reality.

[SoftTalker]

It's very difficult to keep AI focused, when it barfs out 3 pages of reply in response to a one-sentence prompt. It's sort of its nature for some reason, it's very impressive if you've never seen it but it's exhausting to use for very long. It's like a very eager assistant who doesn't have enough experience to understand scope.

[bigmattystyles]

3 pages of reply or overly verbose code, often without abstractions - I read all the posters here and in other forums say that programming has shifted towards reviewing AI output rather than coding said output manually; I agree, however, I just don't buy that everyone is actually reviewing the code as intensely as one would expect - there is a tendency that arrived rather quickly to assume that the AI is correct and efficient. I guess the ultimate reviewer is another AI agent I guess.

[admax88qqq]

I think ultimately you still have to pay down tech debt eventually. Either through bankruptcy (throwaway the project) or servicing the debt (refactoring, rearchitecting etc).

It's not different than when coding by hand, often we take shortcuts by hand that we then have to pay for later. It really just becomes a judgement call on when to stop prompting new features and start service what you have.

I think with AI and vibecoding its tempting to assume the output is good and chase the dopamine hits of more features, more features, more features, but eventually you get stuck.

That being said AI is also a great tool at paying down tech debt. It's great at helping you read a codebase and can be great at making the mechanical changes you want. And I think there is some truth to the story that newer models will be able to pay down debt (fix the slop) of older models. But its all shades of grey, newer models are better than older ones, but can I emit slop with 5.6 faster than 5.7 will be able to fix it in the future? Nobody knows.

It's not like human projects are devoid of bad code, its all tradeoffs and shades of gray. But to be honest I haven't written a line of code by hand in a while.

[a_c]

I find it highly similar between running agents and running human teams.

Clear goal, share context, delegate but verify. Running a team of engineers also inevitably generates pages and pages of material, design spec, code, test, review. Just that we now do that with agents and agents are way less trust worthy

[theshrike79]

What's good for agents is good for humans. That's about it.

The only difference is that agents don't deal well with ambiguity in processes. If your build process is 15 steps, a human will just endure because "that's how it's always been" - an agent will keep stumbling until you either optimise the process or document it.

And now it's better for humans too, they either got a simplified process or better documentation.

[bryanrasmussen]

>It's sort of its nature for some reason

I've known some people who can never stop talking. Maybe they are overly represented in the training set.

[recursive]

> for some reason

Usage is metered/billed by the token. This suggests a few possible hypotheses for why they might tend to be verbose.

[overgard]

The verbosity in code is also a huge problem. I asked it to introduce 4 functions in my project (like, literally, just functions) and I'm looking at 32 files changed and two spec files that are total 200 lines long. It's functional, but jesus, this is going to need a refactor.

[inigyou]

It sounds great for prototyping. Once you do a month's experimentation in a day and generate some shit app that barely works, but looks functional, you have a definite goal to recreate that design but working properly.

[ryandrake]

It seems like an absolute dream for corporate execs who don't know anything about development, see a taped-together prototype built in a day, and think to themselves "Wow, we're 90% done... we could almost ship that!!"

[vitorfblima]

Well, from my experience, if the AI dev is ill intended, he can just say nothing then the exec will go "we can ship now as it is!"

[uwagar]

nobody throws a prototype so this will happen

[chung8123]

On the counter point, it is so much easier to throw away code that cost nothing to build.

[pizzafeelsright]

This was true a while ago. Today we are replacing decades old sloppy production code with 100% verified better code through tests written by AI, code written by AI. This is not looking functional but drop in functional replacement with measurable improvements.

[dfee]

there are two camps: those who have spent the tokens to figure out how to wield AI, and those who haven't. unfortunately, it's not cheap to get to the former category… and i imagine it'd be difficult to lose access to that tooling and fall back to the second category.

[pizzafeelsright]

Experimenting can be pricey but early on I spent my own money thinking "if I can get a handle on how to do this I'll get a 100x return on my money" and it was a good bet.

If you're not convinced - sign up and pay by the token of a high or highest level model. Anthropic or Grok for example. The vendor isn't the concern. The quality of what can be done. Then, find an agentic 'harness' that is written in a language you can read. There are several (pi, opencode, crush, etc) and then clone that repo or one of yours you don't mind having exposed and then point your agent to that repo.

Now ask questions: what api calls are made by this repo? Where are secrets stored and sourced from? Do an adversarial investigation and list the bugs. Then fix the bugs.

Then review the work and determine the value and how to wield this new tool. It replaces reading, writing, and editing - not thinking.

[inigyou]

> It replaces reading, writing, and editing - not thinking.

If that wasn't a hyphen I'd be sure this line was AI-written.

[pizzafeelsright]

You were right to call out the possibility. I assure you, honest take: this is all written myself.

I cannot stand the style of Opus 4.7 and 4.8.

[ReactiveJelly]

You have coworkers who know what a test is? Hire me! ;)

[a_c]

Indeed it is. I’m very grateful to what LLM enables me.

The revelation to me was that I used to code what I know, now I could code what I don’t know. The common path is that when I face something I don’t know, which is quite often, to move forward I have to level up my understanding.

[brightball]

I find the more structure that the AI can be given to follow the better. I recently tried building a side project with Elixir, Phoenix & LiveView but on the recommendation of somebody I decided to have it use the Ash framework within it.

I've been very pleasantly surprised. The combination of the compiler improvements in Elixir 1.20 and the structural guardrails from Ash seems to have led to very consistent, organized and readable code.

[scotty79]

The only two instances where I didn't manage to achieve satisfactory outcome with AI were when I overspecced ahead of time. The things I left out of the spec were implemented in the most undesired manner possible.

The best mode of work for me was gradually sculpting the prototype into a product by providing feedback and moving to version 2 (from scratch but often with v1 accessible as inspiration) if I felt like it's becoming overbloated.

[rukuu001]

As apps get larger and more complex, I get the LLM to produce 'developer documentation'. I find it helps them stay on the rails, and it helps ME stay on top of everything.

The 'spec' frameworks are documentation as well, but can become contradictory as decisions about the app change over time.

[sbloz]

I think the mistake there was the 5 hour session specing the app. It's so hard to know what you want before you see it, so optimize towards seeing it as soon as possible. That's what I thought the article was going to be about based off the title.

Once you have something concrete you can iterate on the prototype until it's a mess. But, hopefully, in that time you got closer to figuring out what you want. And even if the code for the prototype is a mess the "idea" of it should be cleaner. I like to have an LLM make a new spec at that point, and start fresh with it. You can clean up the abstractions and the UX there.

When writing code is cheap figuring out what you want to write is the hard part. It always was, but the barrier of getting the code written and working made that less obvious.

[grebc]

One of the most foundational insights I’ve ever had in IT is clients don’t know what they want until you shove it in their face. And only then do they say no, no, no, change this, this and that.

Same story as building a house. There’s so many unknowns.

[geophph]

it's cunningham's law where the fast LLM generated iteration is the confidently wrong answer that the clients will correct

[cadamsdotcom]

A climbing app..

Does anyone want one?

The article says to stop building and go outside!

And actually, talking about climbing apps with fellow climbers is a great way to be outside.

[a_c]

I climb and I want one :)

> talking about climbing apps with fellow climbers is a great way to be outside.

Indeed. The climbers I met are very supportive. They helped me scan the gym, shared their own climbing footage, which is what I'm trying to do, visualize climbing in a 3D scene.