Hacker Timesnew | past | comments | ask | show | jobs | submit | kaizenb's commentslogin

ツ That was harsh. But true. Workflows are rapidly changing. Hard to adopt. Can we slow down-pause somewhere, so we can focus on building.

Same here. Work through UI, navigating, reviewing and editing repo files easily.

results are important, not the tools or process. (on this matter)

Results over time are important. Or at least they should be.

A curator with a great taste and judgement is king.

Thanks for the video.

His fix for "the dumb zone" is the RPI Framework:

● RESEARCH. Don't code yet. Let the agent scan the files first. Docs lie. Code doesn't.

● PLAN. The agent writes a detailed step-by-step plan. You review and approve the plan, not just the output. Dex calls this avoiding "outsourcing your thinking." The plan is where intent gets compressed before execution starts.

● IMPLEMENT. Execute in a fresh context window. The meta-principle he calls Frequent Intentional Compaction: don't let the chat run long. Ask the agent to summarize state, open a new chat with that summary, keep the model in the smart zone.


More recently I've been doing the implement phase without resetting the whole context when context is still < 60% full and must say I find it to be a better workflow in many cases (depends a bit on the size of the plan I suppose.)

It's faster because it has already read most relevant files, still has the caveats / discussion from the research phase in its context window, etc.

With the context clear the plan may be good / thorough but I've had one too many times that key choices from the research phase didn't persist because halfway through implementation Opus runs into an issue and says "You know what? I know a simpler solution." and continues down a path I explicitly voted down.


That's fascinating: that is identical to the workflow I've landed on myself.

It's also identical to what Claude Code does if you put it in plan mode (bound to <tab> key), at least in my experience.

better to instruct it to write a plan .md file that is appropriately named so that it can be easily referenced/updated in multiple sessions. I've found that effective.

Dunno if you know this but the plan in plan mode is a markdown file! Ask it for the file and it will give it to you.

yes, but if you start a fresh session to continue working on your project, it's a lot easier if you already know which PLAN file you need for your project. Plus you can commit it.

My annoyance with plan mode is where it sticks the .md file, kind of hides it away which makes it annoying to clear context and start up a new phase from the PLAN file. But that might just be a skill issue on my end

Even worse, it just randomly blows away the plan file without asking for permission.

No idea what they were thinking when they designed this feature. The plan file names are randomly generated, so it could just keep making new ones forever for free (it would take a LONG time for the disk space to matter), but instead, for long plans, I have to back the plan file up if it gets stuck. Otherwise, I say "You should take approach X to fix this bug", it drops into plan mode, says "This is a completely unrelated plan", then deletes all record of what it was doing before getting stuck.


It’s not just me then! Hah good to know. It’s why I’ve started ignoring plan modes in most agent harnesses, and managing it myself through prompting and keeping it in the code base (but not committed)

My experience also. The claude code document feature is a real missed opportunity. As you can see in this discussion, we all have to do it manually if we want it to work.

After creating the plan in Plan mode (+Thinking) I ask Claude to move the plan .md file to /docs/plans folder inside the repo.

Open a new chat with Opus, thinking mode is off. Because no need when we have detailed plan.

Now the plan file is always reachable, so when the context limit is narrowing, mostly around 50%, I ask Claude to update the plan with the progress, and move to a new chat @pointing the plan file and it continue executing without any issue.


It’s the style spec-kit uses: https://github.com/github/spec-kit

Working on my first project with it… so far so good.


> RESEARCH. Don't code yet. Let the agent scan the files first. Docs lie. Code doesn't.

I find myself often running validity checks between docs and code and addressing gaps as they appear to ensure the docs don’t actually lie.


I have Codex and Gemini critique the plan and generate their plans. Then I have Claude review the other plans and add their good ideas. It frequently improves the plan. I then do my careful review.

This is exactly how I've found leads to most consistent high quality results as well. I don't use gemini yet (except for deep research, where it pulls WAY ahead of either of the other 'grounding' methods)

But Codex to plan big features and Claude to review the feature plan (often finds overlooked discrepancies) then review the milestones and plan implementation of them in planning mode, then clear context and code. Works great.


Add a REFLECT phase after IMPLEMENT. I’m finding it’s extremely useful to ask agents for implementation notes and for code reviews. These are different things, and when I ask for implementation notes I get very different output than the implementation summary it spits out automatically. I ask the agent to surface all design choices it had to make that we didn’t explicitly discuss in the plan, and then check in the plan + impl notes in order to help preload context for the next thing.

My team has been adopting a separation of plan & implement organically, we just noticed we got better output that way, plus Claude now suggests in plan mode to clear context first before implementing. We are starting to do team reviews on the plan before the implement phase. It’s often helpful to get more eyeballs on the plan and improve it.


How is that Plan strategy not "outsourcing your thinking" because that's exactly what it sounds like. AI does the heavy lifting and you are the editor.

Is a VP of engineering “outsourcing their thinking” by having an org that can plan and write software?

Yes.

Interesting take. Does that mean SWE's are outsourcing their thinking by relying on management to run the company, designers to do UX, support folks to handle customers?

Or is thinking about source code line by line the only valid form of thinking in the world?


I mean yes? That's like, the whole idea behind having a team. The art guy doesn't want to think about code, the coder doesn't want to think about finances, the accountant doesn't want to worry about customer support. It would be kind of a structural failure if you weren't outsourcing at least some of your thinking.

I’m with you, perhaps I just misread some kind of condescension into the “outsourcing your thinking” comment.

We all have limited context windows, the world’s always worked that way, just seemed odd to (mis)read someone saying there’s something wrong with focusing on when you add the greatest value and trusting others to do the same.


It is condescending when antis say AI users do it. It isn’t when a director or team leader does it.

But it’s the same process, which should tell you what’s really going on here. It’s about status, not functionality, and you don’t gain status without controlling other humans.


Delegation is generally all about outsourcing, so hard agree

Closed for $32 billion in cash in March 2026, Google's largest acquisition ever.

What makes Wiz valuable enough that Google couldn't build it in-house, with all the engineering talent they have?


No idea. But I've integrated their API to a commercial project (https://bookmarker.cc) without any issues. Users are exploring The Met Collection and save images to their library directly in the app.

> Through The Met Collection API, users can connect to a live feed of all Creative Commons Zero (CC0) data and 406,000 images from the The Met collection, all available for use without copyright or restriction. The Met Collection API is another foundational step in our Open Access program, helping make the Museum's collection one of the most accessible, discoverable, and useful on the internet. The Met Collection API is where all makers, creators, researchers, and dreamers can now connect to the most up-to-date data and images of artworks in The Met collection, representing five thousand years of human history.

source: https://www.metmuseum.org/perspectives/met-collection-api-2


Works for PR reviews. Separating context for code review with the same model has significant impact.

● Separation of concerns. No single agent plans, implements, and verifies. The agent that writes the code is never the agent that checks it.


Thought and came up with nothing.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: