Many folks here likely have some stack that looks like: Google Workspace, GitHub, Vercel/Railway/Render/etc. where env vars or secrets are hosted. These are all loosely coupled but transitively trusted.

So compromising any one of them becomes a threat vector. In other words, if System A trusts System B, and System B trusts System C, then System A trusts System C. This is also why OpenClaw is frightening from a security perspective.

Also, this is a good reminder to run audits. Run `npm audit` on a typical Next.js project and you’ll probably see DoS vulnerabilities, ReDoS issues, Prototype pollution, code injection paths, handlebars etc. I'm sure you'll find something unexpected if you don't have routine code hygiene checks.

Otherwise, AI definitely impacts learning and thinking. See Anthropic's own paper: https://www.anthropic.com/research/AI-assistance-coding-skil...

But here's the reality. What got you technically to PMF may hold you back from your Series A and next steps. Technical debt is just the natural cost of growth, but (here's the kicker) optimizing tech stacks too early can lead to slower execution time. Most startups never reach exponential scale anyways. Put another way, starting with "rocket ship" does not immune the startup from rewrites, refactoring or throw away code.

The real systems and management challenge is building architectures that are intentionally temporary or modular. Simple enough that throwing them away later isn’t traumatic and rebuilds aren’t a sign of failure but success.

Channeling Steve Blank, get out of the building! You’ll run into real problems faced by real people who often have limited exposure to both AI and tech, but who can still benefit enormously. Listening and engaging is always a good first step before jumping in to suggestions.

In this space, needs are far more data and visualization driven, which are not strictly AI related. It may also be both a useful and humbling antidote to hype cycles.

Trade secrets are far cheaper and easier to maintain than patents. In short, patents are only as strong as your ability to enforce them. Also Alice Corp. v. CLS Bank International (2014) weakened software and process patents. That said, if you can’t realistically defend IP in court, you effectively don’t have it. From an early-stage founder perspective, that makes patents a questionable use of time and money and potentially what kills the company.

This may contrast from information you get from a lawyer or VC. Patents are attractive because they create an asset someone else can later buy or defend. For the founder, the incentives aren’t squarely aligned.

Neither approach is more right or wrong, but there are very real practical consequences. If you are pre-seed who is bootstrapped or done a family & friends round and are pre or early revenue, trade secrecy is by far your better option.

As an additional note, if you don't own the underlying AI models and are just a better wrapper for Claude or ChatGPT you at best have a very weak IP or patent position.

https://www.wired.com/story/i-infiltrated-moltbook-ai-only-s...

In product management (my domain), decisions are made under conflicting constraints: a big customer or account manager pushing hard, a CEO/board priority, tech debt, team capacity, reputational risk and market opportunity. PMs have tried with varied success to make decisions more transparent with scoring matrices and OKRs, but at some point someone has to make an imperfect judgment call that’s not reducible to a single metric. It's only defensible through narrative, which includes data.

Also, progressive elaboration or iterations or build-measure-learn are inherently fuzzy. Reinertsen compared this to maximizing the value of an option. Maybe in modern terms a prediction market is a better metaphor. That's what we're doing in sprints, maximizing our ability to deliver value in short increments.

I do get nervous about pushing agentic systems into roadmap planning, ticket writing, or KPI-driven execution loops. Once you collapse a messy web of tradeoffs into a single success signal, you’ve already lost a lot of the context.

There’s a parallel here for development too. LLMs are strongest at greenfield generation and weakest at surgical edits and refactoring. Early-stage startups survive by iterative design and feedback. Automating that with agents hooked into web analytics may compound errors and adverse outcomes.

So even if you strip out “ethics” and replace it with any pair of competing objectives, the failure mode remains.

Comments URL: https://news.ycombinator.com/item?id=46947833

Points: 2

# Comments: 1

https://www.instagram.com/p/DUTSLcjkfJn/

Particularly in a brownfield development context, using AI to research issues, gaps, bugs, tech debt, reusable patterns etc. as research files is really useful. I find the sweet spot is ~750 lines for each file. Planning files can max out at 1,500 lines if needed or otherwise broken up into individual phases. You can always ask an LLM to create a starter set of docs to get you going and then maintain as you go along.

For the management nerds, none of this is new. See: Writing Effective Use Cases by Alistair Cockburn and Agile Specification-Driven Development by Ostroff, Makalsky and Paige. The fundamentals remain the same and I'd say become even more important in a brownfield context with a high degree of tech debt or complexity. Greenfield is a different story.

What's important with spec driven development is that the LLMs dramatically reduce the cost of both good documentation and good technical specifications. Once you have a good plan and good references, you can build anything with a high degree of accuracy.

I'd add caution about drift. The more documentation you shove into the context, the worse things can get. You can also create a beautiful and perfect functional spec that becomes a swiss cheese of gaps when you create your technical implementation plan. Always check and use different AI models adversarially to ensure you are actually getting the plan you want. Usually ChatGPT can spot Claude's blind spots, for example. And always test manually.

https://www.wheresyoured.at/why-everybody-is-losing-money-on... https://www.economist.com/business/2025/12/29/openai-faces-a... https://finance.yahoo.com/news/openais-own-forecast-predicts...

You can see the very different response by OpenAI: https://openai.com/index/our-approach-to-advertising-and-exp.... ChatGPT is saying they will mark ads as ads and keep answers "independent," but that is not measurable. So we'll see.

For Anthropic to be proactive in saying they will not pursue ad based revenue I think is not just "one of the good guys" but that they may be stabilizing on a business model of both seat and usage based subscriptions.

Either way, both companies are hemorrhaging money.

1. Turing test UX's, where a chat app is the product and the feature (Electron is fine) 2. The class of things LLMs are good at that often do not need a UI, let alone a chat app, and need automation glue (Electron may cause friction)

Personally, I feel like we're jumping on capabilities and missing a much larger issue of permissioning and security.

In an API or MCP context, permissions may be scoped via tokens at the very least, but within an OS context, that boundary is not necessarily present. Once an agent can read and write files or executed commands as the logged in user, there's a level of trust and access that goes against most best practices.

This is probably a startup to be hatched, but it seems to me this space of getting agents to be scoped properly and stay in bounds, just like cursor has rules, would be a prereq before giving access to an OS at all.

Using slash commands and agents has been a game changer for me for anything from creating and executing on plans to following proper CI/CD policies when I commit changes.

To Codex more generally, I love it for surgical changes or whenever Claude chases its tail. It's also very, very good at finding Claude's blindspots on plans. Using AI tools adversarially is another big win in terms of getting things 90% right the first time. Once you get the right execution plan with the right code snippets, Claude is essentially a very fast typer. That's how I prefer to do AI-assisted development personally.

That said, I agree with the comments on tokens. I can use Codex until the sun goes down on $20/month. I use the $200/month pro plan with Claude and have only maxxed out a couple times, but I do find the volume to quality to be better with Claude. So far it's worth the money.

This was a very refreshing interview.