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.
It's not empowering to hand off the details
141–150 of 154 posts
Re: It's not empowering to hand off the details
#142I'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'…
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
#143I'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…
- 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
#144Earlier 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…
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
#145All 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.
Re: It's not empowering to hand off the details
#146Earlier 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…
Re: It's not empowering to hand off the details
#147Earlier 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.
Re: It's not empowering to hand off the details
#148Earlier 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.
Re: It's not empowering to hand off the details
#149Earlier 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.
Re: It's not empowering to hand off the details
#150Earlier 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?
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.