evolve-maz

I agree architecture is important. But I think the best way to design a good architecture is to have a high level plan, and then feel it out by coding parts of it (usually near component edges / interfaces) in the actual domain with real use cases.

That exploration helped me see whether general "best practices" are applicable in this frame, and let me justify if not.

That was also prevailing opinion pre LLM:

> Only the hands on engineers can shape it since the design evolves in step with writing the code.

So I'm curious to know where people changed their minds.

It's interesting to see how over the span of just a few years a lot of people went from:

> Architecture astronauts are out of touch and shouldn't give any advice because they haven't written code in ages. Only the hands on engineers can shape it since the design evolves in step with writing the code.

To

> I focus on the architecture patterns and high level goals and let the LLM take care of the rest.

Similar commentary was shared about anyone not writing the code daily, not just the architects.

No gotchas, I just think it's something which calls for introspection.

Only in the last few years did I start using SQL properly. Before that my pipelines would live in python. Now I offload as much to the db as possible, and keep my python simple glue. I'm very happy with this compared to other methods in pandas or polars.

If I still need to do db-like things in python I think duckdb is better.

I also really enjoy programming, and relate to your comment below about sometimes waking up in the middle of the night because your brain figured out how to code a hard problem.

Sorry to hear you're having a rough time with work. I do think AI availability has made otherwise smart people put out lazy work. But I also think that there are more people who still "code by hand" than you think.

You might find some joy by going to certain events where people talk about different items coding-wise. I enjoyed the talks for this conference recently https://www.youtube.com/@softwareshouldwork (particularly Richard Hipp's, Delaney Gillilan's and Carson Gross' talks), maybe you can find similar spaces. The benefit has been Youtube's algorithm recommending me better software talks now too.

I've spent many years doing work in compliance for airlines. Hundreds of pages of documentation to describe the different rules and regulations which must be followed in specific scenarios. We'd convert those documents into a programmatic definition (rule engine) to alert when rules are at risk of not being followed.

This work was fraught with bugs, a large portion of which came down to disagreement of what was coded v/s what was written. Even if you had airlines sign off sentence by sentence exactly what you wrote down in English, that's too open to interpretation.

People don't appreciate how the same sentence can be read five different ways by different people (or the same person on different days). We had to structure our documents to be closer to pseudo-code than to English to get any meaningful consensus on the definition.

I use this pattern for my makefiles. First item is for "help", and it dynamically scrapes all the other commands (assuming format <command>: ## <description>). So if I do 'make help' it'll list all the commands in the makefile without much extra work from me.

.PHONY: help

help: ## Show this help message

@grep -E '^[a-zA-Z_-]+:.?## .$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' @echo "" @echo "Examples:" @echo " make deploy" @echo " make deploy-branch BRANCH=feature-x" @echo " make deploy AUTO_START=true"

.PHONY: deploy

deploy: ## Deploy from current branch (default main) (use AUTO_START=true to restart service after)

@$(MAKE) _deploy BRANCH=$(git branch --show-current)

Yep, the poke pattern is additionally nice because it means my state reconciliation function is the same when running on cron interval vs event driven.

On the flip side, it helps to have endpoints which have a query param linking to some sort of resource update time stamp. That way you can query to only get those items changed since last poll.

Anthropic releasing things like Cowork explains why they wouldn't want you to host the model and retain your data.

They need that data so they can push into wider job automation, displacing the SaaS companies who used Anthropic in the first place.

Here's a common workflow:

- Ask cursor to summarize your existing repo to write you a nice readme

- Cursor opens repo

- Cursor looks at current code

- Because it's going above and beyond, it also wants to give you some metadata about the code (other branches for things in development, maybe previous tags as milestones, etc)

- To do that, it runs some git commands

Now the malicious behavior. I ask Cursor to evaluate some remote repo. It clones it down and then runs the git command from the working directory. However, if you just call "git ..." from the command line there is ambiguity about that. What if there's already a git file in the directory which windows thinks you want to execute?

This could happen with an untrusted repo. Or could happen from you switching branches to a compromised branch (which you wouldn't expect to immediately run some code).

Normal way to handle this is using fully qualified path names for things. E.g. instead of git ... you give the full path to system installed git. Annoying for humans to type but trivial for Cursor.

I've been a manager for some years. Without sounding too up myself, what made me good at management was the fact that I knew how to do the things I asked people to do. It allowed me to critically evaluate the work, set realistic timelines, and champion the contributions up the chain. I also maintained the ability to perform this work (by design and happenstance sometimes, since we could be understaffed due to sickness etc).

The good managers I saw also had this ability. The managers I didn't enjoy working with / saw struggle were ones who either never had that ability, or had lost it a long time ago.

Note I'm speaking about line management. There's a world of difference between managing a dozen or so individual contributors vs managing senior managers / directors. However, managing LLMs is analogous to line management.

I wouldn't accept that junk from any engineer in my team.

My experience with good developers has been:

- Create something a bit ugly which works

- As more use cases come in, refactor code and clean up old gnarly bits

LLMs tend to work architecture astronaut style mixed with a junior for implementation. Build theoretically good interfaces but then implement dependencies across all of them. And when changes happen, keep feeding that cycle.

A lot of rules like "some fields are hidden / shown based on other fields" come from restricting users to only expressing valid object states. E.g. I have a form where a user can pick a "notifier". They get a first dropdown select which is email or teams-message. Then based on that selection to get another which fills the details relative to that.

In that case, the backend will likely have a class instancr representing it, with the first field being a discriminator on the class and the remaining fields being the details. And regardless of what the frontend does, the backend will revalidate always because you can never trust data sent from a frontend.

All that to say, maybe the form could be server side rendered, with an adaptor to convert a class definition into an html form fragment, and either embedding the js "rules" into the html itself, or making it a web component for containered usage.

Doing it this way is a big deviation from the current status quo, but I've found it to work very well and cut out a whole range of bugs. Plus it makes me think about what is truly client side state (no chance of staleness) vs server state cached in client to avoid repeat server calls (could be stale, leads to bugs).

I haven't seen a code base which hasn't fallen into degradation from that loop.

From personal experience, any "correction" leads to an LLM writing more code, or stripping apart interfaces and mixing logic poorly, or adding some hidden control flow just to catch that edge case rather than the general case for that category of input.

That's because the assumption is the new product can already do what their current product can, so the things customers ask for is the extras. It's really easy to forget that a lot of work went into "baseline" features which are assumed to be standard (in this case the not burning part).

If I flag every line in your PR as a potential security bug then I have 100% recall.

Obviously you need a mixture of high recall and low false positive rate. If 7/8 flagged items are fine its much more likely people will ignore the warnings, much like they would any security tool with a 90% false positive rate. That is not optimized for the customer.

My advice would be to only use HTMX for data state related operations. For something like an intelligent back button, unless it depends on resource state do not use the backend to calculate it.

The recommended htmx way would be to hook up an onclick button to inline js or if you dislike that, a function called goBackOrInbox. It can then be something like:

function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }

And if you use that pattern a lot then you can parameterise the function with whatever the route should be.

All the talking points and techniques are those which were used when pushing outsourcing: give better specs, write detailed tests, accept bad code because it works so who cares, we can just rewrite from scratch later, and my favorite "they will get better with more exposure to your code base". None of these takes is wrong, but what they neglect is doing all that work is way more effort than if I wrote the original code myself.

Using an LLM to one shot a small function (something i would do with a very specific search on Google or SO) is handy. Giving it a harness and free access to a code base leads to some terrible code, and doubling down with more instructions and agents in the loop means more time writing the rube Goldberg orchestration rather than just opening up an editor and writing code.

Nice write-up. Did you try the problem out against a MIP method?

Presentation of data and a story is a very important part of the service. That's why we have a mix of pictures, tables, paragraphs, etc. It's why UX is so important in general.

Expertise isn't there because people are outsourcing that sort of work to companies. I didn't know how to do much of anything, until I had to do it for work. Then learning everything became way easier.

Htmx has events you can listen to like htmx after response. You can think of it almost like a middleware. After the response comes in, your callback is triggered and you can make the callback look up some attribute given the calling parents attribute that you might call hx-json-key.

Yes you have to add this yourself, but you only need to add one js function once and be done with it.

I've used the callback pattern for custom error handling for all hx responses.

FYI I had a similar problem to yours in terms of having jobs I wanted to run on a schedule. I also had an extra layer where I wanted to let users to define jobs with their own special parameters etc. Maybe what I did is helpful for you:

- Form submission in front-end admin panel for users, for "new scheduled job"

- Form allows defining a job name, job type (while I let users define jobs, I limit it to a subset of python functions that I trust but are still general enough), job parameters (just a json blob for kwargs for the python func), frequency, and timeout.

- For the whitelisting of functions it's easiest to have a directory in your src which has the different python functions that are usable, and when you do a "get" for the form you populate the dropdown with the scripts from that directory / some metadata.

- The backend (fastAPI) saves the details in a DB and creates a CRON file for the job, to add to the crontab. I basically have a template bash statement with the timeout built in and logging hooked up to it. And when python functions are called I have a helper which grabs the JSON kwargs from the DB or a filecache (if remote DB and I don't want to hit it every minute or something) to avoid cmd line injection.

- Also have an "edit scheduled job" which opens the same form view but with items pre-populated, and the submit going to a patch endpoint instead of a post.

It's stupid simple but lets users define a range of jobs. Things like having daily backups, where to send the backups, pulling things from / pushing things to an API frequently, etc.