Live data from Hacker News

It's not empowering to hand off the details

davidnicholaswilliams.com

141–150 of 154 posts

Re: It's not empowering to hand off the details

#141

Earlier quoted context omitted.

How would you do it if you hired an employee in your company to do it? You'd talk to the employee and read the docs they write. Same here.

When an employee writes a system, the employee owns the system. When an AI writes a system for you, YOU own the system.

Owns? What a strange word to use. I doubt they own it in the sense that the profits of it go to their bank account. Use a better word and things will be clearer.

Re: It's not empowering to hand off the details

#142
post #19

I've been vibecoding a ton for the past 9 months, built a bunch of cool little apps for myself with AI, ran experiments, built an entire SDLC on skills, did the agent orchestration harness thing, etc. In the past few weeks I've hit a wall where I'm just tired of it. Each model becomes more independent but also harder to direct in detail. They produce massive, tedious, sloppy text outputs with very little input. They'…

> ensures that I'm in the driver's seat

This is why I'm still primarily using tab complete. Maybe will spin up an agent here and there to add tests or for repetitive work where I can say "follow the approach I just did for this one case across all remaining cases"

Re: It's not empowering to hand off the details

#143
post #19

I've been vibecoding a ton for the past 9 months, built a bunch of cool little apps for myself with AI, ran experiments, built an entire SDLC on skills, did the agent orchestration harness thing, etc. In the past few weeks I've hit a wall where I'm just tired of it. Each model becomes more independent but also harder to direct in detail. They produce massive, tedious, sloppy text outputs with very little input. They'…

Similarly for me. I have a recent example too. I run a bunch of eps32 devices at home, using esphome. Pre-AI I wrote all the yaml myself and understood what’s happening and didn’t have any very bespoke hacks. Recently I asked an agent for a feature where the screen will get dimmer after some time, and eventually after a day the screen will turn off and then turn back on if I tap, which should be pretty easy in esphom…

IMO this points to two things:

- You didn't have the agent plan and de-risk/experiment beforehand

- You didn't glance at the output

Working with agents is not very different from working with other engineers.

You write a design doc, share it with others, divvy up the work. You get to review some % of the code and make sure the implementation is reasonable. You leave comments for the important issues rather than trying to obtain pure/perfect code.

One of the biggest difference IMO is that you cannot really mentor an agent (other than prompting e.g. with AGENTS.md/skills)

Agents, just like engineers, can create needlessly complex code/systems. If you want a good result, you need to ask why did they do it X way and consider alternatives.

Re: It's not empowering to hand off the details

#144

Earlier quoted context omitted.

Similarly for me. I have a recent example too. I run a bunch of eps32 devices at home, using esphome. Pre-AI I wrote all the yaml myself and understood what’s happening and didn’t have any very bespoke hacks. Recently I asked an agent for a feature where the screen will get dimmer after some time, and eventually after a day the screen will turn off and then turn back on if I tap, which should be pretty easy in esphom…

IMO this points to two things: - You didn't have the agent plan and de-risk/experiment beforehand - You didn't glance at the output Working with agents is not very different from working with other engineers. You write a design doc, share it with others, divvy up the work. You get to review some % of the code and make sure the implementation is reasonable. You leave comments for the important issues rather than tryin…

True, I didn’t do those in detail. I vaguely looked at the output and thought “let’s see if that works at all”.

I do such more careful planning and AI handholding at work where it’s important the thing doesn’t break in prod, or doesn’t forget about some important use case.

But this was just purely for “fun” / homelab style type of vibe coding where I don’t want it to feel like work and write intricate specs and handhold the agent - point being the current SotA models still currently do need a bunch of guidance to not devolve into a code spaghetti, and it does end up feeling like ‘work’.

Re: It's not empowering to hand off the details

#145

All details are not created equal. Some details are boring. My AI dream (that I’m living happily) is getting to focus on the details that I find interesting and ignoring all the boilerplate details that modern software requires.

So what? Jobs aren't supposed to be fun. Lots of people depend on those boring details.

Saying jobs aren't supposed to be fun is akin to saying life should be dreadful. Work tends to be around half of your waking hours, usually your best and least tired half too. If anything we should be striving to make all kinds of work more enjoyable.

Re: It's not empowering to hand off the details

#146

Earlier quoted context omitted.

Similarly for me. I have a recent example too. I run a bunch of eps32 devices at home, using esphome. Pre-AI I wrote all the yaml myself and understood what’s happening and didn’t have any very bespoke hacks. Recently I asked an agent for a feature where the screen will get dimmer after some time, and eventually after a day the screen will turn off and then turn back on if I tap, which should be pretty easy in esphom…

IMO this points to two things: - You didn't have the agent plan and de-risk/experiment beforehand - You didn't glance at the output Working with agents is not very different from working with other engineers. You write a design doc, share it with others, divvy up the work. You get to review some % of the code and make sure the implementation is reasonable. You leave comments for the important issues rather than tryin…

This is an extremely good advice - thank you

Re: It's not empowering to hand off the details

#147

Earlier quoted context omitted.

When an employee writes a system, the employee owns the system. When an AI writes a system for you, YOU own the system.

Owns? What a strange word to use. I doubt they own it in the sense that the profits of it go to their bank account. Use a better word and things will be clearer.

Yes, owns. Ownership as in accountability, stewardship and care. But I think you already got this from my post and if we're fighting about semantics, there's no constructive discussion to be had.

Re: It's not empowering to hand off the details

#148

Earlier quoted context omitted.

I've been hit with the team manager trying to clear tickets on the jira board with entirely AI generated code, and what I've observed is they always make the system more complex, usually absurdly complex. The AI code never looks at things from a higher level, or reconsiders the requirements, it just layers on a load of crap until the tests pass.

It does that, yeah. But my experience mostly in codex with gpt 5.5 and 5.6 is that if you micromanage it enough you can get clear code. It just gets really annoying to repeatedly do that.

[flagged]

Re: It's not empowering to hand off the details

#149

Earlier quoted context omitted.

Owns? What a strange word to use. I doubt they own it in the sense that the profits of it go to their bank account. Use a better word and things will be clearer.

Yes, owns. Ownership as in accountability, stewardship and care. But I think you already got this from my post and if we're fighting about semantics, there's no constructive discussion to be had.

Accountability - yes, you can fire a human. But you can also fire the AI, by switching to a different model or switching back to manual coding. The rest just depends on having a strong enough model.

Re: It's not empowering to hand off the details

#150

Earlier quoted context omitted.

To me, being able to do something I could not, is unequivocally better.

Cool. Can you show us some great new things you have done with AI?

I'm not going to show you but I'll tell you, because I'm hoping you're asking in good faith and not just being snarky.

With AI, I now have tools to analyze recorded demos from quake 3 and pull metadata from them, match them against recorded match statistics, and most importantly, split a large multi-match demo file into multiple separate matches/files which are all self-contained.

Doing this required the LLM to review the source for q3 to determine how to re-create gamestate and correct various aspects that were non-trivial due to huffman encoding.

I also patched the server to be able to stream demos to attached clients, so multiple people can watch a demo simultaneously. It can now seamlessly switch between demo-playing and game-serving. I've had multiple PRs to the main repo merged for this.

All these are far, far beyond my ability to do by myself, and none of these features/functions were really available in 2026. There are some long-abandoned demo tools out there, but they either don't work, don't compile, or otherwise are windows-only. My demo tools are python, and of course the q3 server code is c++.

These aren't great new things. They're not ground-breaking. They're merely new things I made for me and my friends. And I think it's great.

Post reply on HN