| ▲ | jlos 2 hours ago | |
(1) Spending time building a plan. I have lots of artifacts like diagrams, tables, web pages that help me think through all the details quickly. Get code snippets to reduce uncertainty, get options for architectural decisions, flesh out assumptions. Main thing is (1) how do I verify the agent hits the happy path and (2) how can I elicit and clarify assumptions it might make. Then follow up the build with exploring and refactoring. (2) prioritized context switching (like playing an RTS) I have several tasks going at once, while one works I hop onto other tasks. I usually have one or two “core” goals I’m trying to accomplish that take deeper thinking and get priority. The other tasks are smaller and require less thinking. A lot of times I’ll have the secondary agents build research docs I can review in detail later. | ||
| ▲ | rbartelme 2 hours ago | parent | next [-] | |
Yeah, I definitely do something similar with my personal projects. I come from more of a hardware & environmental engineering background and we were always taught that projects were iteratively built via Design, Build, Test, Learn cycles. I drive the Design and basic skeleton of the build (pseudocode or boilerplate), then pass off the rest of the Build and Test to the agent. I pick up after the test and read the agent commits/notes, then write up next steps. Repeat DBTL. Maybe spin a few features out at a time in parallel depending on how much time I want to devote to reviewing new project features later in the day. | ||
| ▲ | spike021 2 hours ago | parent | prev [-] | |
I think planning is a big part. ironically, this wasn't a part of my typical routine as an engineer before AI came around. Sure I thought through the work or ticket I was assigned but not always at as much of a birds eye view. Nowadays with AI I try to start most tasks with a plan, review each phase/step, research parts I'm more unsure of, and try to refine it. Ironically it's more of a dev cycle like process anyway IMO. | ||