Agentic Coding Recommendations

> "Today is the worst day you will have with this technology for the rest of your life."

Why do we trust corporations to keep making things better all of a sudden?

The most jarring effect of this hype cycle is that all appear to refers to some imaginary set of corporate entities.

I trust it more with Rust than Python tbh, because with Python you need to make sure it runs every code path as the static analysis isn't as good as clippy + rust-analyzer.

> Last night I had a file with 38 mypy errors

Fixing type checker errors should be one the least time consuming things you do. This was previously consuming a lot of your time?

A lot of the AI discourse would be more effective if we could all see the actual work one another is doing with it (similar to the cloudflare post).

Whats your workflow? Ive been playing with Claude Code for personal use. Usually new projects for experimentation. We have Copilot licenses through work so I've been playing around with VS Code agent mode for the last week. Usually using 3.5, 3.7 Sonnet or 04-mini. This is in a large Go project. Its been abysmal at everything other than tests. I've been trying to figure out if I'm just using the tooling wrong but I feel like I've tried all the "best practices" currently. Contexts, switching models for planning and coding, rules, better prompting. Nothings worked so far.

> Is there more we can add to the AI conventions markdown in the repo to guide the Agent to make fewer mistaken assumptions?

Forgive my ignorance, but is this just a file you're adding to the context of every agent turn or this a formal convention in the VS code copilot agent? And I'm curious if there's any resources you used to determine the structure of that document or if it was just a refinement over time based on mistakes the AI was repeating?

> you wouldn't be able to tell from my git history.

I can easily tell from git history which commits were heavily AI generated

> There was a worry that code would become big mud balls

That's always been a worry with programming (see basically all Rich Hickey talks), and is still a problem since people prefer "moving fast today" instead of "not having 10 tons of technical debt tomorrow"

LLMs makes it even easier for people to spend the entire day producing boilerplate without stopping for a second to rethink why they are producing so much boilerplate. If the pain goes away, why fix it?

"There was a worry that code would become big mud balls that only AI understand, but it looks like the opposite."

For now...

I was struck by this too. Good error messages, fast tools, stable ecosystems, simple code without magic, straight SQL… it’s what I always want. Maybe agents will be what raises the bar for dev experience, simply because they work so quickly that every slowdown matters.

> Does this mean that eventually in a world where we all use this stuff, no new language/framework/library will ever be able to emerge?

I highly doubt it. These things excel at translation.

Even without training data, if you have an idiosyncratic-but-straightforward API or framework, they pick it up no problem just looking at the codebase. I know this from experience with my own idiosyncratic C# framework that no training data has ever seen, that the LLM is excellent at writing code against.

I think something like Rust lifetimes would have a harder time getting off the ground in a world where everyone expects LLM coding to work off the bat. But something like Go would have an easy time.

Even with the Rust example though, maybe the developers of something that new would have to take LLMs into consideration, in design choices, tooling choices, or documentation choices, and it would be fine.

> So using agents forces (or at least nudges) you to use go and tailwind

Not even close, and the article betrays the author's biases more than anything else. The fact that their Claude Code (with Sonnet) setup has issues with the `cargo test` cli for instance is hardly a categorical issue with AIs or cargo, let alone rust in general. Junie can't seem to use its built-in test runner tool on PHP tests either, that doesn't mean AI has a problem with PHP. I just wrote a `bin/test-php` script for it to use instead, and it figures out it has to use that (telling it so in the guidelines helps, but it still keeps trying to use its built-in tool first)

As for SO, my AI assistant doesn't close my questions as duplicates. I appreciate what SO is trying to do in terms of curation, but the approach to it has driven people away in droves.

A traditional digital stack's lifecycle is:

1. The previous gen has become bloated and complex because it widened it's scope to cover every possible miche scenario and got infiltrated by 'expert' language and framework specialists that went on an atrotecture binge.

2. As a result a new stack is born, much simpler, back to basics, than the poorly aged encumbant. It doesn't cover every niche, but it does a few newly popular things realy easy and well, and rises on the coattails of this new thing as the default envoronment for it.

3. Over time the new stack ages just as poorly as the old stack for all the same reasons. So the cycle repeats.

I do not see this changing with ai-assisted coding, as context enrichment is getting better allowing a full stack specification in post training.

Just yesterday I gave Claude (via Zed) a project brief and a fresh elixir phoenix project. It had 0 problems. It did opt for tailwind for the css, but phoenix already sets it up when using `mix phx.new` so that's probably why.

I don't buy that it pushes you into using Go at all. If anything I'd say they push you towards Python a lot of the time when asking it random questions with no additional context.

The elixir community is probably only a fraction of the size of Go or Python, but I've never had any issues with getting it to use it.

> Does this mean that eventually in a world where we all use this stuff, no new language/framework/library will ever be able to emerge?

That's a very good question.

Rephrased: as good training data will diminish exponentially with the Internet being inundated by LLM regurgitations, will "AI savvy" coders prefer old, boring languages and tech because there's more low-radiation training data from the pre-LLM era?

The most popular language/framework combination in early 2020s is JavaScript/React. It'll be the new COBOL, but you won't need an expensive consultant to maintain in the 2100s because LLMs can do it for you.

Corollary: to escape the AI craze, let's keep inventing new languages. Lisps with pervasive macro usage and custom DSLs will be safe until actual AGIs that can macroexpand better than you.

I’m wondering whether we may see programming languages that are either unreadable to humans or at least designed towards use by LLMs.

> Does this mean that eventually in a world where we all use this stuff, no new language/framework/library will ever be able to emerge?

If you truly believe in the potential of agentic AI, then the logical conclusion is that programming languages will become the assembly languages of the 21st century. This may or may not become the unfortunate reality.

My best results have been with Ruby/Rails and either vanilla Bootstrap, or something like Tabler UI, Tailwind seems to be fine as well, but I'm still not a fan of the verbosity.

With a stable enough boilerplate you can come up with outstanding results in a few hours. Truly production ready stuff for small size apps.

Same. I have a very efficient workflow with Cursor Edit/Agent mode where it pretty much one-shots every change or feature I ask it to make. Working inside a CLI is painful, are people just letting Claude Code churn for 10-15 minutes and then reviewing the diff? Are people even reviewing the code?

Exact same experience. I have no clue what other people are doing. I was hunting for use cases where it could be used and it kept not working. I don't get it.

it shouldn't be expensive - you can pay for Pro ($20/month) or Max ($100 or $200/month) to get what would cost >> $1000/month in API costs.

> Java has the largest, oldest and most explicit data set for the LLM to reference

That seems to be a recommendation for coding with LLMs that don't have access to tools to look up APIs, docs and 3rd party source-code, rather than something you'd chose for "Agentic Coding".

Once the tooling can automatically figure out what is right, what language you use matters less, as long as source code ends available somewhere the agent can read it when needed.

Agree much with your 2nd point though, all outputs still require careful review and what better language to use than one you know inside-out?

Why is this? is there just a insanely large codebase of open source projects in Java (the only thing i can think of is the entire Apache suite)? Or is it because the docs are that expressive and detailed for a given OSS library?

I always assumed the LLMs had the most python code to reference, as they seem to default to Python most often if you don't specify

Agreed on all points.

The only place I’ve encountered this pattern is in chromedp, the go wrapper for the chrome headless browser driver. Its API… isn’t good.

Most methods you use are package globals that take a context.Context as a first parameter. But you have to understand that this context is a _special_ one: you can’t pass any old context like context.Background(), you must pass a context you got from one of the factory methods.

If you want to specify a timeout, you use context.WithTimeout. Clever I guess, but that’s the only setting that works like that.

It’s essentially a void*.

I'm really not an expect in Go, but the data that I'm passing at the moment via context is the type of data which is commonly placed there by libraries I use: database connections, config, rate limiters, cache backends etc. Does not seem particularly bad to me at least.

Honestly, I find this approach to be useful pretty much anytime you're working with other people as well.

There are absolutely times to be extremely focused and clever with your code, but they should be rare and tightly tied to your business value.

Most code should be "blindingly obvious" whenever possible.

The limit on developers isn't "characters I can type per minute" it's "concepts I can hold in my head."

The more of those there are... The slower you will move.

Don't create more interfaces over the existing ones, don't abstract early, feel free to duplicate and copy liberally, glue stuff together obviously (even if it's more code, or feels ugly), declare the relevant stuff locally, stick with simple patterns in the docs, don't be clever.

You will write better code. Code shouldn't be pretty, it should be obvious. It should feel boring, because the hard part should be making the product not the codebase.

> What do you recommand to get a Claude-code-like experience in the open-source + local llm ecosystem?

There is nothing at the moment that I would recommend. However I'm quite convinced that we will see this soon. First of all I quite like where SST's OpenCode is going. The upcoming UX looks really good. Secondly because having that in place, will make it quite easy to put local models in when they get better. The issue really is that there are just not enough good models for tool usage yet. Sonnet is so shockingly good because it was trained for excellent tool usage. Even Gemini does not come close yet.

This is all just a question of time though.

Aider is almost there, in fact it's intentionally "not" there. You can set it up to do things like run test/static analysis automatically and fix errors, and work with it to get a to-do list set up so the entire project is spec'd out, then just keep prompting it with "continue...". It has a hard coded reflection limit of 3 iterations right now, but that can also be hacked to whatever you want. The only thing missing for full agentic behavior is built in self prompting behavior.

Shameful plug: my upcoming app perhaps?

Single-file download, fuss-free and install-less that runs on mac, windows and linux (+ docker of course.) It can run any model that talks to openai (which is nearly all of them), so it'll work with the big guys' models and of course other ones like ones you run privately or on localhost.

Unlike Claude Code, which is very good, this one runs in your browser with a local app server to do the heavy lifting. A console app could be written to use this self-same server, too, of course (but that's not priority #1) but you do get a lot of nice benefits that you get for free from a browser.

One other advantage, vis-a-vis Armin's blog post, is that this one can "peek" into terminals that you _explicitly_ start through the service.

It's presently in closed alpha, but I want to open it up to more people to use. If you're interested, you and anyone else who is interested can ping me by email -- see my profile.

I see a new alternative (or attempt at one) come out every few days, so it shouldn't be long before we have "the one" alternative.

https://www.app.build/ was just launched by the Neon -- err, Databricks -- team and looks promising.

The Neovim plugin CodeCompanion is currently moving into a more agentic direction, it already supports an auto-submit loop with builtin tools and MCP integration.

Yes it's not a standalone CLI tool, but IMHO I'd rather have a full editor available at all times, especially one that's so hackable and lightweight.

I’m also interested to hear ideas for this.

Try Aider with API usage. Learn how to control context size (/clear, /add, /drop). Limit context to 25K. Use whatever model you want (Sonnet 4 or Gemini 2.5 Pro).

For simple scripts, it often costs me under $1 to build. I'm working on a bigger tool these days, and I've done lots of prompts, a decent amount of code, over 100 tests, and my running total is right now under $6.

I'd suggest learn the basics of using AI to code using Aider, and then consider whether you want to try Claude Code (which is likely more powerful, but also more expensive unless you use it all the time).

One month at 20 USD seems like it should be plenty to try it out on a small project or two to decide wether it is worth trying 100 bucks/month? Or one can just wait a couple of months as people report their learnings.

You can use Claude Code either pay-as-you-go with an API key, or subscribe to the $20 Pro subscription.

I think this discussion boxes new students into the mediocre category right from the start.

Do we really want to tell Fabrice Bellard that he isn't productive enough?

If you want to train people to become fungible factory workers on the other hand, train them to work on the conveyor belt.