Ask HN: I use coding agents daily, but how do real engineers use them?

3 points by getlawgdon 48 days ago | 8 comments

I have a broad but shallow technical background (longtime management consultant) and use agents (a variety of services and models in VS Code) extensively for my own projects. I know I'm hitting a ceiling. My workflow is naive and nonpro, a lot of tinkering and bashing my way through code generation, context drift, manual fixes, etc.

I want to learn how senior engineers treat these tools. Processes, systems, guardrails, must-dos, etc.

If you write code for a living and have integrated agents into your workflow, what does your system look like?

Any/all input is welcomed: resources, URLs, outlines, warnings, discoveries, recommendations.

None of these are specifically needed, but ideas?

-How do you structure a brand new project? Scaffolding, git init/ignore? Repos? Initial commit strategies? How do you keep stuff out of the context window that you don't want in it?

-How do you "layer" your work so it's much more about the context and integrity of the structure and much less about prompts?

-Do you switch models (often? ever)? Why?

-What other tooling do you have alongside basic agents/environments?

-What are "pro habits" that I don't have and should?

-Any suggestions for how to work in a very domain-specific endeavor to try to increase the utility of the agents for a silo like this?

blinkbat 48 days ago |

I don't find that the models are so capable that the workflow can be "much less about prompts". you still need to be in the loop, prompting and validating, to get good output. people will say otherwise -- I say those people are full of shit, have an adverse incentive, or don't have high standards.

getlawgdon 48 days ago | |

Thanks. I could have phrased that better. What I meant was that so much of my work has been about the prompt that I feel like I'm neglecting where the rest of the process is.

verdverm 47 days ago | | |

https://www.youtube.com/watch?v=zaDbZt40kRg

Check out this video on things you probably aren't using. A lot of people felt the immediate productivity boost from just prompting and aren't digging deeper into their tools and what they offer

ativzzz 48 days ago |

> How do you structure a brand new project? Scaffolding, git init/ignore? Repos? Initial commit strategies?

Don't overthink it. Use whatever bootstrapping tools your project framework comes with (rails app? use `rails new`)

> How do you keep stuff out of the context window that you don't want in it?

Don't overthink it. Just use one chat per general topic. New topic -> new chat. Save anything relevant to the project that the agent doesn't pick up in new chats in AGENTS.md

> How do you "layer" your work so it's much more about the context and integrity of the structure

Save project specific needs/requirements in AGENTS.md or docs/ or skills or whatever and tinker until it works

> Do you switch models

Nowadays just for code review. Recently gpt5.5 has felt very good for general dev

> What other tooling do you have alongside basic agents/environments?

Neovim for code browsing (don't write much code anymore but the code editor is still useful for reading code) and various plugins/tools i've built up over the years

Honestly, there's no blanket solution. The best engineers I've worked with all have different tools custom to their workflows

> know I'm hitting a ceiling. My workflow is naive and nonpro, a lot of tinkering and bashing my way through code generation, context drift, manual fixes, etc.

Hit a ceiling? Fix it. Typically it's

- do work

- notice something annoying about your workflow

- fix it systemically - research different solutions - sometimes it's writing a small script (agents are great for this), sometimes it's finding a new tool, sometimes it's overhauling your entire system, it just depends

- do work

repeat...

there's really no one stop solution for a perfect workflow

getlawgdon 47 days ago | |

Thanks for this.

david_freepay 46 days ago |

One pro habit you need is dealing with change orders and part of that has to do with whether you have an easier or more difficult client to please. For example, a difficult client will ask for "tweak" but if you're a pro, you don't bite. Anything that would take me over 2 minutes to do, I charge another 0.5 hours just for the trouble. I got tired of the friction associated with scoping engineering modifications on fixed-fee technical contracts, so I built an un-paywalled utility widget to calculate exact project profit drag. It cross-references your foundational contract metrics against unbilled change orders to map out the decline in your true hourly compensation. Features an adjustable client maintenance friction multiplier to automate premium calculation. Built entirely with clean vanilla JS and raw semantic HTML—no cookies, trackers, or marketing gates. To stress-test a contract, search freepaycalc on Google and select the Scope Creep tool.