Remote: Yes (Only)

Willing to Relocate: No

https://ryanguill.com

https://www.linkedin.com/in/ryan-guill-92034a1/

CV: https://ryanguill.com/resume/

I am an experienced, driven, motivated engineer who is looking for high-agency, high-impact problems to solve. Bonus points for roles that are a positive impact on society.

Looking for remote roles in majority remote teams. I'm comfortable in startups and large corporations, I just want to ship fast on things that matter.

Postgres/Snowflake/DuckDB, Typescript, Python, AWS, Docker, LLMs and related tech - but I love learning new languages. I ask a lot of questions, and think in terms of processes and systems. I use and build agents and love a good SQL query.

email: ryanguill+hn@gmail.com

You shouldnt put things in AGENTS.md that it could discover on its own, you shouldnt make it any larger than it has to be, but you should use it to tell it things it couldnt discover on its own, including basically a system prompt of instructions you want it to know about and always follow. You don't really have any other way to do those things besides telling it every time manually.

I don't think im in terrible shape right now, but looking ahead 10 to 20 years, without medical intervention I probably would be.

I believe for some of us its purely genetic.

This is true to an extent for sure and they will go much longer than most engineers without getting "tired", but I've def seen both sonnet and opus give up multiple times. They've updated code to skip tests they couldn't get to pass, given up on bugs they couldn't track down, etc. I literally had it ask "could we work on something else and come back to this"

Buildings with higher people/sqft could already take advantage of indoor co2 scrubbers today.

The hard part is capture and disposal.

Theres a lot of network effects as well. The more people were using it, the more people will use it.

Data should be data, queryable, relational. So often I have had to change enums into lookup tables - or worse, duplicate them into lookup tables - because now we need other information attached to the values. Labels, descriptions, colors, etc.

My biggest recommendation though is that if you have a lookup table like this, make the value you would have made an enum not just unique, but _the primary key_. Now all the places that you would be putting an ID have the value just like they would with an enum, and oftentimes you wont need to join. The FK makes sure its valid. The other information is a join away if you need it.

I do wish though that there were more ways to denote certain tables as configuration data vs domain data, besides naming conventions or schemas.

Edit to add: I will say there is one places where I have begrudgingly used enums and thats where we have used something like prisma to get typescript types from the schema. It is useful to have types generated for these values. Of course you can do your own generation of those values based on data, but there is a fundamental difference there between "schema" and "data".

Did you consider making this a view instead? Just curious if there is a reason why you couldn't.

So if youre building your own agent, this would be a directory of markdown documents with headers that you tell the agent to scan so that its aware of them, and then if it thinks they could be useful it can choose to read all the instructions into its context? Is it any more than that?

I guess I dont understand how this isnt just RAG with an index you make the agent aware of?