codeprimate

LLM's are information processors. Linters on steroids.

Don't talk to them? Maybe that's the issue..treating them like people instead of the text processors that they are.

I use LLM's consistently every day and haven't had a "chat" with one in many months. Issue commands and request documents. The whole "thinking machine" role-play makes the tool dumber, not smarter, and corrupts your own patterns of thinking into ones that are dependent rather than imperative.

Conversation is literally the least interesting and most error prone use case that LLM's can provide.

Location: Bellingham, WA

Remote: Yes

Willing to relocate: No

Technologies: Ruby, Rails, PostgreSQL, Sidekiq, Hotwire, JavaScript, Python, AWS, Docker, MCP, LLMs, RSpec

Résumé/CV: https://www.linkedin.com/in/patrick-morgan/

GitHub: https://github.com/codeprimate

Email: contact at bellingham.dev

I have been shipping software for twenty years, most of it Rails, and what I own has always run wider than the code I write. The work starts in a room where most of the people are not engineers and the problem has not been named yet, and it carries through the data model, the API contract, the authorization boundary, the background queues, the deploy, and whoever holds the pager afterward. Being accountable across that whole span is a broader claim than full stack, and a harder one to fake.

The depth sits in Rails and Postgres, where I have built async pipelines that had to survive real traffic, payments and third-party integrations that could not quietly drop money, and authorization models that grew more intricate every quarter as the business kept inventing new kinds of users. I reach for Hotwire when the product needs a face, run Docker daily, and treat application security as ordinary hygiene rather than a phase, which means reading the CVEs that touch my stack, running Brakeman and bundler-audit, and reviewing changes against OWASP before they land.

I work with agents every day and skeptically, on the same practice I was using before the tooling existed: discovery before implementation, verification before reference, scope control before anything ships.

Two of the more interesting systems I built are ones I argued to shut down, once the numbers showed they cost more than they were worth, and I wrote up the reasoning both times so the decision outlived the project. That judgment matters more to me than shipping volume, because I would rather be right in month three than committed in month nine.

I am looking for senior IC, staff, or principal work on a team with clear direction and problems worth the depth, whether that runs toward Rails and backend architecture, greenfield systems design, or LLM work that has to earn its place in the product. Available now.

This hits too close. I was doing poorly at work for a few months with much the same symptoms: anxiety, severe brain fog, lethargy, etc. On good days I was at maybe 30%. A few days after being laid off I went to the dentist to extract a cracked molar because I was starting to experience vertigo and suspected a infection. Almost a week later I feel like an entirely different person: Sharp. Composed. Energized. Back to the self I almost forgot.

Apparently I had a slow burn infection that dragged me much much harder than I realized.

No doubt...health issues can seem superficially minor, but impact you in significant ways that are nearly impossible to correlate.

You MUST use RAG (retrieval augmented generation) for ChatGPT to be generally useful for programming.

I use a ChatGPT-based script using RAG to work with code-bases. I include text documentation included in the repository, descriptions of application and folder conventions in the documentation folder, and file paths for source information in the augmented prompt. The documentation it creates is nearly as good as my own and I feed the output back into the documentation folder for even better understanding of the application.

I am working on an effective prompt to enforce overall implementation style and approach. ChatGPT strays toward system-agnostic and lower-level abstractions instead of application conventions. Conventions at a higher level of abstraction are a subtle but important aspect of the application theory.

Can definitely relate here. I've been accused of "mansplaining" and aggressive communication more than once, when I am only intending to communicate clearly and directly the same way I always do with everyone all the time. Clear communication isn't an insult. The tendency that some people have for unnecessary and unfounded offense is utterly obnoxious.

This has already been weaponized. I've been getting comment spam phishing attempts from Google service accounts and Google Docs linking to scripts like this: "REDACTED://script.google.com/macros/s/REDACTED/exec?sl=REDACTED&dn=REDACTED&t=moc&s=au&sec=s&"

I am not sure what the script does or how to analyze it without risking my account security.

It's a fact that I don't have an internal monologue. I didn't understand that people actually thought in words until I was a teenager.

I think the only thing that saved my career was dropping out of college 2 years early in 2000. I immediately started working in a print shop doing data processing work and earning my chops and programming experience through self-directed automation and process improvements. My friends in retail earned more than me, but I learned far more in 4 years there than college would have made possible. Leveraging my Linux and general programming experience I moved on to web development work in 2004 at a tiny consulting company based in the upstairs living room of my boss. We did "lean" and "agile" right and survived through the bust by wearing all of the hats and working hard. We could provide high quality solutions for half the cost quoted by large competitors. The pay was simply ok (but my colleagues and employer were amazing). Later, with a baby on the way I had to move on for better pay. Leaving was hard, but finding a position wasn't with all the experience I earned at a cut rate.

In short: I grew, barely survived financially, and made excellent connections.

The idea that one should be compelled or be obligated to support a group or organization that acts against one's morals is abhorrent.

I am sure that much of the open source developer community does not share the author's moral flexibility. Those that do can fill the void of products or services that conscientious objectors may no longer provide.

I don't see how it's possible to code without a mental model. It's like drawing something without "seeing" it.

That sounds really really hard.

It sounds like you need something like rocket.chat

I keep notes of tasks, problems, solutions, caveats, and references. This makes for a highly searchable and understandable knowledge base. Anything beyond that proves to have little utility in the long-term.

Spend half your time learning many things shallowly and half your time learning a few things deeply -- your resourcefulness will know no bound.

This is VERY similar to a site I helped write back in 2009 called RiledUp.com. Unfortunately it never took off.

I hope this platform has better luck.

Not a lawyer.... If any in-house libraries were used this becomes a problem if changes or updates to those libraries were written during development of Fallout Shelter. Any subsequent versions of those libraries would become tainted and verboten from use in other products. Even any fixes to those libraries after initial distribution to correct bugs in the game could reasonably be argued to fall under the contract.

In practice exclusivity restrictions demand a from-scratch product. Developers are cheaper than lawyers.