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.
I'm one of (if not the) original architecture astronaut, so you may not want to listen to me, but you're sliding from "architecture astronauts are bad" (true) to "architecture doesn't matter" (false).
Arguably, architecture is the only thing that ever mattered. Below the level of architecture you're dealing either with algorithms or API calls. Algorithms can be validated by tests and API calls can be validated by tests and the type system.
But architecture is the one thing that could make or break a project and that you can't test for ahead of time. You either know how to create a good architecture or you don't. In fact, the whole point of the Spolsky's Architecture Astronauts' essay is that bad architecture (and bad architects) are a big problem.
AI works amazingly well below the level of architecture, but (I've found) it's not very good at architecture.
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.
I think your argument is you can't create good architecture without writing code. I sort of agree. You can't be a good software architect without knowing how to code, and you can't be a good architect of a specific code base without being familiar with the code.
But I don't think you expect an architect to have written all the code, right? I don't even think you expect an architect to have read all the code.
The whole point of being a good architect is understanding the abstractions so that we can focus on the overall system without necessarily knowing all the details. I don't need to know the FFT math behind JPEG to integrate an image library.
So there's no real change in opinion. Architects were never expected write or even understand every line of code.
I think they are lying to themselves. The patterns change with the hardware and environment, i sure code different and use other data structures when having to account for VRAM now, network security, etc.
Going from the specification to the code is not a one way street. You adapt the whole chain. Saying the only thing that matters is the spec is squinting your eyes and hoping for the best.
You stop learning how things actually end up in memory, compute, storage and network this way. Not sure how you can build a secure and fast spec then.
And even if you do know i never understand why not typing it out. You can use a lib if you don't want to worry about these details or know you are not skilled enough (tls f.e. ...). But having AI do it introduces uncertainty where there can be determinism.
I think it's just laziness and people not liking the pain of learning or needing to show off whatever first. Who knows. Still don't see a reason to use these tools outside of learning or whatever i used a google search for before.
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.
Thanks for the recommendation, I in fact couldn't sleep past 5am today and woke up to check an SQLite presentation on that channel. Pure gold!
I think that's how it is, we just gotta fine-tune the algorithms on our favor. I'm doing it slowly with Youtube (I'm into rock climbing recently, and it's been a fun ride on YT). My Twitter feed can actually be pretty amazing, even my IG one. I don't check them much often any more but they're still pretty good. No BS.
The trick is not to fall for the stupid videos with millions of views. I just recently learned about Mukbang or something like that (a weird trend where people binge eat on YT). Crazy
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.
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.
- 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.
> There's a world of difference between managing a dozen or so individual contributors vs managing senior managers / directors.
I agree, but in my opinion, your point about needing to know how things work still holds. It's less relevant as you move up to managing managers and larger orgs, but it never goes to zero if you're going to be successful.
I think it holds true throughout if you scope it to knowledge about your reports’ domain. If you’re managing managers you should have a good handle on what a manager does and different ways to do it.
There's two huge aspects of management that gets diluted when it's compared to "managing" an LLM:
- labor laws. You need to know those in the country where the employee has their contract, because this will restrict what you can (and must) do in your managerial role
- Empathy. Managing humans is extremely messy and requires a ton of EQ to do well (parents have first-hand experience of this).
So, i.e: comparing being a manager to real humans vs instructing a next-token generator dilutes the skill of being a good manager and leader.
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).
> 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.
reply