I suggest keeping an eye out. We have regular internships and positions for those out of college. For eng, we’re backfilling right now with a focus on seniors. But our general need is for contributors who can work with our stack. Our code is all public. AI code generation and skill with the frameworks we need is our general trajectory.
Reasoning model prompting is relevant here. OpenAI in their docs state that giving detailed, step-by-step instructions often hinders reasoning models. It's better to clearly define the outcome along with what you're working with. Then let the mode interpolate.
Do you have any of those examples handy by chance? Curious to check them out. And agreed! While coding has become a commodity - programming is still as alive as ever.
Absolutely agree with that last sentiment. Recently I came across a project by a former google engineer called Dyad: https://github.com/dyad-sh/dyad
This is built to be a lovable/bolt alternative and is definitely on the early side in terms of total capability and reliability. But once you start digging through the source you realize how much engineering actually went into building it. Not just chaining prompts together in a dart throwing exercise and praying for a good result.
This is much closer to the "turnkey" solution vertical I mentioned in my earlier commentary, since its meant to generically build any web app, but there's a few applied concepts that are shared with the promptyped approach used in the HTTP/2 server (though not as sophisticated when compared to the category theory / type theory approach).
I think it's a good example to work backwards from though, if you peel the onion a bit you realize how much more tightly you could scope this for more bespoke projects.
I haven't fully stress tested it, but from brief use their proprietary context engine just feels like a gimmick to draw in VC investments. You can't convince me you get better end performance using an older model. Especially as most AI coding tools draw closer to enshitification with opaque context compression to save on costs
YMMV, but I've found it really does work and isn't a gimmick. It gets problems right that Cursor, Roo, Windsurf, etc trip up on because somehow it finds exactly the relevant stuff for context at a granularity you can't really achieve by @mentioning whole files/directories in other tools. I'm going to enjoy it at least until something better comes along. I think the "relevant accurate context is better than just adding more context" approach is the way to go.
I find the autocomplete model a lot better than cursor/copilot as well. IMO it does a much better job of understanding the intention of your changes and generating relevant changes across files. I think that's also due to the context engine, it checks for relevant changes to the task at hand across files rather than being mostly "local".
Adding to the conversation, Cursor is really genuinely good. Their agentic system has solid system prompts, better than Roo imo.
Their UX is absolutely the best as well. Excluding maybe Claude Code (completely different tho). You can argue what's better, what deserves to stand as a standalone product, but Cursor is easily the most mature 'vibe coding' tool imo.
Yes. It's definitely noticeable. Though, I try to console myself by remembering that my architectural design is definitely hypertrophied. My code is ultimately better. I think my LLM-assisted problem solving is definitely more efficient as well. My code literacy is better.
Hopefully LLMs won't vanish away... I'd be at a net negative.
