What about errors compounding and any on-the-go decisions being made being the wrong ones? That kills anything long form, no matter how good and detailed your initial plan is - there will always be something along the way.

The models would need a way to identify a difficult problem and apply max reasoning there themselves and cruise through everything else at a lower level.

github.event.issue.title is very obviously data. It should never be POSSIBLE to treat that as an instruction.

Furthermore, the idea of any code being able to access the tokens instead of allowlisted software and only with specific commands, and also no housekeeping to prevent the DATA of the token from ever being sent to anything other than a desired host… all of it feels fundamentally wrong.

The fact that our OSes don’t help with that is so saddening.

Implement features at a viable pace and drown any unrealistic expectations in reports of CVE fixes - usually a version bump of dependencies, but quite often also some migration work within the app; write tools to make that work visible like I did with scanning and reports, and enjoy living without having to complain about how you can’t keep up with releases while letting your software rot until it’s a multi-year migration.

Alongside that, do the same for test coverage as well because it’s the humans that have been sloppy for years and didn’t work enough on the test harnesses or good enough coverage, introduce Testcontainers and load testing tools and anything else that makes sense.

Use their money for tokens to build software that is actually good and make your life easier and ensure that their shortsightedness won’t sink the product on a few years.

Of course you could also get fired if they’re stupid, but then I don’t imagine that working for those that are delusional is exactly great either, unless the goal is explicitly to make slop to get investor money in which case the whole thing will probably need to be rewritten from scratch anyways so who cares.

I've done amounts of refactoring and fixes and written tooling that just wouldn't have happened before.

I'm not sure what amazing new stuff y'all expect but the amount of technical debt in my projects is actually going down, cause I can finally get good enough test coverage, including E2E/load tests that actually prove whether the software works and scales or doesn't - just last week I diagnosed issues with SeaweedFS failing under concurrent writes when backing Sentry and could swap it out for Garage in a day, caught by a monitoring tool I slopped together that integrates with the Sentry API, no issues since.

The environment around me has gone from drowning in tech/ops debt to sort of swimming and at least holding above water for now (cause nobody will pay for 5x more tokens).

It's also insanely good for prototyping and being able to actually explore various ideas and shoot the bad ones down quickly instead of handwaving and looking at a loaded calendar, alongside being able to address well bounded tasks in parallel, better than human developers can - like I can give 5 GitHub issues to the slop machine and have it fix all of the annoying bugs. Issue with how some data shows up? Just feed it the DB dump and let it find out what's up.

Some projects have gone from around 500 code tests to around 4000, and before anyone says they're meaningless, at least 5% of those have caught real issues and helped a bunch, alongside linters and other tooling (including some tools I wrote myself). I've also written both native utilities and some web platforms for myself, side projects that I never would have gotten around to.

I'm measurably more productive than I've ever been (since I did measure that, looking at my commits over the last 2 years) but also burnt out. Still, it's the kind of burnout that's the consequence of context switching and lots of work, rather than the kind that I had years ago, where I had to manually untangle deeply nested Spring Boot service logic all over the place at like 2 AM cause the made up deadlines were kicking my butt.

In contrast to others, I don't need to move the goalposts - the productivity for me is here and now. Any future models will just make it better, unless we experience model collapse.

Disclaimer: you do need a LOT of code tests and validations, otherwise it all goes to shit. Maybe I'm just extending how much time it will be until it goes to shit for me as well, but go figure. You also have to babysit the models more than anyone would like or should, most of my work usually has 20-60 minutes of planning before dispatching the agent.

I wonder how long it'll be until they won't need to do that due to domestic options.

Would be nice. I feel like the more you go towards the 3rd world (or tbh anywhere not in the US), the more this calculus shifts, probably all the way to underspecced workstations, no IDE licenses (e.g. JetBrains) and also no investment into tokens or whatever.

Also, 10k USD per year seems a bit low, I'm not tokenmaxxing but my non-subscription usage equivalent would be around 3000-6000 USD per month, though obviously with models like Kimi K3 and GLM 5.3 it would be way more sensible compared to Anthropic.

Not informing the user of that feels wrong, and even then you'd probably want like a dropdown to choose between just the current session vs the last 5 if that much context is really needed, with either Off or 1 being the default.

Claude Code has a clear disclaimer, probably exactly how it should be done:

> Submitting this report will send the entire current conversation to Anthropic for future improvements to our models. Learn More

Heh, snarky.

I guess (almost) everyone uses PgBouncer because they want to use a setup that will need the scaling needs of most users from the get-go, to avoid wasting support time.

Personally, I run without it due to a fairly small scale - I don't need more than about 128-256 connections max and for me a dedicated connection pooler (other than what's sometimes used app-side) would just add complexity.

At the same time, one could totally reasonably make the argument that if almost everyone uses it, then it SHOULD quite possibly be a built in feature, instead of a separate component - such a tighter integration would most likely bring the overall complexity down.

Consider asking it to use sub-agents or dynamic workflows for that, then the context will be polluted less by the surrounding stuff, UNLESS you wanna babysit it through let's say 5-10 files first and then write down the desired results in some plan file that each of the sub-agents would get.

Personally, Opus 5 has been kinda inconsistent for me - sometimes the technical capabilities are very much there, other times it's a bit dumb, but almost always the tone is insufferable and obnoxious LinkedIn speak, no matter what I try. Nowadays using Kimi K3 and GLM 5.3 more, though they exhibit similar issues with performance, grass is greener only in regards to tone.

I’d rather wait 5-10 years for a stdlib way of handling JSON, XML, YAML, TOML and other formats than using unproven libraries made with unserious practices that have edge cases. The same applies for processing requests, doing any sort of multiprocessing, DB interaction, validations, hell even any and all front end work all they way down to CSS. Don’t even get me started on desktop and server software and OS stuff.

Maybe then software engineering can be treated like real engineering.

The videos that document the journey probably haven't gone anywhere:

https://www.youtube.com/@randyprime/videos

https://www.youtube.com/@randyprime2/videos

If you want to make an engine and learn about making engines - make an engine.

If you want to ship a game - think long and hard about whether an off-the-shelf engine wouldn't be a better investment of your time (because you wouldn't invest hundreds or thousands of hours making something bespoke and could actually make the features you need within an existing engine).

I suspect that with the great FOSS and source available engines we have, like Godot, there will be plugins for msot things and folks will be able to make their own without having to start from scratch (unless they really want to), like the most competent terrain implementation for Godot so far is a plugin - https://tokisan.com/terrain3d/

Hell, maybe also contribute to lesser known engines if you feel like it: like jMonkeyEngine, Flax (it's great, like a lightweight and 3D oriented Unity / Unreal with a footprint closer to Godot and a nice C# integration), Stride and others.

Currently 20% of my 5 hour limit and 4% of my weekly limit.

  Total: 58.46M
  GLM-5.3 Cached: 56.91M
  GLM-5.3 Uncached: 1.23M
  GLM-5.3 Output: 315.18K
  Cache hit rate: 97.9%

            Full 5-hour  Full weekly
  Total     292.3M       1.461B
  Cached    284.6M       1.423B
  Uncached  6.15M        30.75M
  Output    1.576M       7.88M

Their own estimates are quite different, probably due to their conservative caching estimates vs what I normally get on longer form work: https://docs.z.ai/devpack/overview#estimated-token-allowance

I agree, but then we just need meaningful benchmarks that clearly show that! Otherwise it's hand waving about something that should be put on paper in quantifiable terms.