Who is this good for? My company, Anthropic/Openai, but not me? Maybe if I was investing in a side project I’d feel differently.

At any rate, the thought of bringing the agent out of my work machine and into my pocket or bed with me is terrifying. I hope it doesn’t come to that.

I guess the author has never worked on a dog shit system with no tests at all and constant downtime.

I have worked with “complexity averse” engineers who would rather fix the edges over and over again, than roll up their sleeves and just get the job done.

I just don’t believe that using new tools is at odds with avoiding complexity.

Sometimes you have to take it to the chin, and get to use the new shiny thing along the way to move much faster.

- programmatically enforce your style with in-house linters and scaffolders. Be highly opinionated

- if you # ignore anything, leave a comment explaining why

- use bdd so your cases are human readable and must update with the code (unlike a stale comment)

- follow the same pattern in all your services (I love hexagonal design for backend). If you break from the design have a good reason for it

- COMPOSE your code. It’s almost always the case that two endpoints or jobs or whatever happen to have a few things in common, but differ wildly. Don’t get DRY, just import those things in each spot and don’t entangle them with each other, it’s too confusing

- scope your interfaces tightly. No optional params unless the domain is actually optional. Make separate jobs or endpoints for different configs. I can’t figure out wtf all your configs were from 4 years ago and neither can you

- code is default testable with DI/DIP

- always run tests running real infra like testcontainers - cement ci/cd as your guardian. Employ every linter you can.

- hammer workarounds with comments in the code

- break all systems into small problems and nothing is challenging technically (though the domain might be!)

- work with less people on your code. It’s easier to stay aligned and follow the same patterns

- don’t expect anyone to figure it out. You need to champion your changes. Do code reviews, hold their hand, show them the way

- clear out mundane items like installfests, local auth, server reloads. Slow dev pisses people off

- finally, and most important, employ an org policy for review. Don’t let shit fall through the cracks unknowingly. It compounds. You have skills now as a quick and dirty to eval and enforce. Use them!

Not really. Today I learned of a story where a vibe coding PM deployed a vercel app, which was in its entirety a single react component that serves a banner, that was embedded via an iframe into an entirely separate web app, whose repo they have full access to, because they needed to get a modal component out the door, but were blocked because they “couldn’t upload the image to s3.” (They could just use the public/ or assets/ directory and have the cdn pick it up, too.)

People do the most insane things when they are tight on time and don’t have the intuition to do a bit of research up front. If you ask them, they’re solving the immediate problem at hand. If you ask anyone else who interacts with their work, they’re disrupting our days/weeks/months/years when we have to step through systems that don’t know any better.

If you have the muscle to plan ahead, even a little bit, which is usually just following the same pattern over and over again, then you are fine.

In this world you are still optimizing for the now problem but you have also solved, to some and ideally a better degree, some future problems for free

Says who? One of the most enriching things about coding with agents is I have them provide new information, tools, patterns, whatever as a follow up to every feature I work on. I’m learning a ton and it’s helping me build better with agents, too.

Markdown files are a good reference but they are a weak enforcement tool and go stale easily.

Avoid burying yourself in more skills docs you’re not even writing yourself and probably never even read. Focus that toward deterministic tooling. (Not that skills or prompts are bad, I agree a meta skill that tells an agent what subagents and what order to run is useful)

> An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism.

My question is why isn’t there an effort from the author to mitigate the insane things that LLMs do? For example, I set up a hexagonal design pattern for our backend. Claude Code printed out directionally ok but actually nonsensical code when I asked it to riff off the canonical example.

Then, I built linters specific to the conventions I want. For example, all hexagonal features share the same directory structure, and the port.py file has a Protocol class suffixed with “Port”.

That was better but there was a bunch of wheel spinning so then I built a scaffolder as part of the linter to print out templated code depending on what I want to do.

Then I was worried it was hallucinating the data, so I wrote a fixture generator that reads from our db and creates accurate fixtures for our adapters.

Since good code has never been “explained for itself 100%, without comments”, I employ BDD so the LLM can print out in a human readable way what the expected logical flow is. And for example, any disable of a custom rule I wrote requires and explanation of why as a comment.

Meanwhile, I’m collecting feedback from the agents along the way where they get tripped up, and what can improve in the architecture so we can promote more trust to the output. Like, I only have a fixture printer because it called out that real data (redacted yes) would be a better truth than any mocks I made.

Finally, code review is now less focused on the boilerplate and much more control flow in the use_case.

The stakes to have shitty code in these in-house tools is almost zero since new rules and rule version bumps are enforced w a ratchet pattern. Let the world fail on first pass.

Anyway, it seems to me like with investment you can slap rails on your code and stay sharp along the way. I have a strong vision for what works, am able to prove it deterministically with my homespun linters, and am being challenged by the LLMs daily with new ideas to bolt on.

So I don’t know, seems like the issue comes down to choosing to mistrust instead of slap on rails.

Edit: I wanted to ask if anyone is taking this approach or something similar, or have thought about things like writing linters for popular packages that would encourage a canonical implementation (I have seen some crazy crazy modeling with ORMs just from folks not reading the docs). HMU would love to chat youngii.jc@gmail

1. git is not going away 2. git UX is not great

So i appreciate their effort to manage development better as agents make it possible to churn out multiple features and refactors at once.

BUT, I reject this premise:

3. Humans will review the code

As agents make it possible to do so much more code (even tens of files sucks to review, even if it’s broken into tiny PRs), I don’t want to be the gatekeeper at the code review level.

I’d rather some sort of policy or governance tooling that bullies code to follow patterns I’ve approved, and force QA to a higher abstraction or downstream moment (tests?)

This is my experience. Tests are perhaps the most challenging part of working with AI.

What’s especially awful is any refactor of existing shit code that does not have tests to begin with, and the feature is confusing or inappropriately and unknowingly used multiple places elsewhere.

AI will write test cases that the logic works at all (fine), but the behavior esp what’s covered in an integration test is just not covered at all.

I don’t have a great answer to this yet, especially because this has been most painful to me in a React app, where I don’t know testing best practices. But I’ve been eyeing up behavior driven development paired with spec driven development (AI) as a potential answer here.

Curious if anyone has an approach or framework for generating good tests

Anyway, as a result, I switched to Claude Code Max and I am equally as prolific and paying 1/10th the price. I get my cake and to eat it, too. *Note there’s a Cursor Ultra, which at quick glance seems akin to Claude Code Max. Notice that both are individual plans, I believe I’m correct you benefit from choosing those token-wise over a team or enterprise plan?

Anyway, you’re right Claude Code is less ergonomic; generally slower. I was losing my mind over Opus in Cursor spinning up subagents. I don’t notice that happen nearly as frequently in Claude Code itself. I think it has to do with my relatively basic configuration. CC keeps getting better the more context I feed it though, which is stuff like homegrown linters to enforce architecture.

All to say, Cursor’s pricing model is problematic and left a bad taste in my mouth. Claude Code seems to need a bunch of hand holding at first to be magical. Pick your poison

But I haven’t seen examples of products or software produced by these setups. Does something like Product Hunt exist for agentic coded things?

Worth noting here that I’m not a skeptic nor advocate. I work with coding agents daily and I see their utility. I also feel their pains. I’d love to lean in more but I don’t see tangible evidence beyond “more code”

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

Points: 2

# Comments: 0

I’ve been building out internal linters that enforce design patterns I want and raise common code smells (also note tools like eslint allow custom rules which are easy write with something like opus 4.6). The use case is a total refactor of react and fastapi apps. We are suffering from everything’s a snowflake syndrome and just want the same pattern employed across features.

This works pretty well when the linter has a companion agents.md file which explains the architecture and way about the world.

But to get the agent (Claude code opus 4.6 currently) to nail the directory structure and design primitives, and limit some doofus behavior, I still haven’t cracked how to make literally each line of code simple and sensible. And I haven’t figured out how to prevent agents from going out of bounds and doing weird things unless I catch it in review and add another rule.

This is a relatively new endeavor, but my gut is that it’s not much more time (linter rules and perhaps “evals” or a beefy agent review cycle) before I have bespoke linters in place that force what I want from our architecture.

Note that a huge bottleneck to all of this is that the codebase our current team inherited has no tests. It’s too easy to accidentally nuke a screen’s subtle details. It’s also really hard to write good tests without knowing what all of the functionality is. It feels like a blocker to a lot of large-swath agentic changes is a test strategy or solution first then a rigid push for rearchitecture or new design.

We tried to get as much mileage as we could out of Postgres before we switched to clickhouse and it was night and day.

But but but, in some scenarios it has been at the expense of my well being. It’s not good to take on more work and not let go of some of the things you’re currently doing. Moreover, finding “permission” from your boss to let those things go can be challenging.

I’ve found this works best when you and your boss agree on the problem you’re stepping into (not necessarily your solution). It may be that you need to stick your neck out and suffer for awhile for them to see your perspective.

When you’re on the same page about what you’re solving, a good manager will clear room for you.