define observable behaviors, let codegen workout most of the rest by implementing the contract.

decompose specs into proper units (a hundred lines or so), not god-awful, unreadable, vibe-coded, frankenstein documents. follow the software engineering best practices you've honed for the last 25 years.

you end up slowing down, sitting in the problem, figuring out "the right problem to solve", all the benefits of writing the code. but now you have a spec to iterate on, and the behavior statements in the spec generate code and tests from a single source of truth (each statement a provable assertion).

as bugs arise, trace back to the spec. changes often end up being a single line of text in the spec which cascades into an easy to review diff plus tests.

spec prose allows writing "why" and "how" together without code comments which go stale.

and lean on your type system to leverage opportunities to be terse, creating a spec which has fewer words, yet still produces strong correctness guarantees (aka, the spec can be shorter than the code, and still be readable).

bonus: versioning a spec is easy, so now you have a change signal when reviewing your peer's code changes. be more careful with major/minor bumps, skim patch bumps.

while many of my peers are taking the giant-ass sdd approach, shipping fast, and losing touch with the actual system behavior, ive been taking the approach outlined above with a modest 2x speedup in feature delivery (their speedup appears much larger), without losing touch with the underlying system.

i am working on large, complex, overgrown, legacy code, so i dont have the luxury of floating in a vibe coding cloud, miles above the scary jungle and tigers and lava and spike traps that i call home.

ive found this approach to be a brilliant balance of speed, incremental AI opt-in, hands-on to avoid context loss, and most importantly to me: maintainability.

i suspect a subset of "proper" ai-codegen software engineer tooling and flows will settle in this vicinity.

encourage folks to swiftly vibe-code prototypes, but then from there, let software engineers do what we do best: engineer software, and transform the protoypes into something maintainable.

Maybe something has materially changed?

What are they even supposed to do with feedback on the code? It has to be translated by my teammate into the language of the work they did, which is the conversation they had with the AI agent.

But the conversation isn't the "real work": the decisions made in the conversation are the real work. That is what needs capture and review.

So now I know why code reviews are kinda wrong, what can we do to have meaningful reviews of the work my teammates have done?

What I landed on is aiming to capture more and more “work” in the form of a spec, review the spec, ignore the code. this isn't novel or interesting. HOWEVER...

For the large, messy, legacy codebases I work in today, I don’t like the giant spec driven development approach that is most popular today. It’s too risky to solely trust the spec because it touches so much messy code with so many gotchas. However, with the rate of AI generated code rolling in, I simply can’t switch context quickly enough to review it all efficiently. Also, it’s exhausting.

The approach I have been refining is defining very small modules (think a class or meaningful collection of utils) with a spec and a concise set of unit tests, generating code from the spec, then not reading or editing the generated code.

Any changes to the code must be made to the spec, and the code re-generated. This puts the PR conversation in the right place, against the work I have done: which is write the spec.

So far the approach has worked for replacing simple code (eg: a nestjs service that has a handful of public methods, a bit of business logic, and a few API client calls). PRs usually have a handful of lines of glue code to review, but the rest are specs (and a selection of “trust” unit tests) and the idea is that the code can be skipped.

AI review bots still review the PR and comment around code quality and potential security concerns, which I then translate into updates to the spec.

I find this to be a good step towards the codegen future without totally handing over my (very messy and not very agent friendly) codebases.

Scamming may not be new, but a person using AI in this way is able to penetrate quite deeply into (long, tedious, time-consuming) interview process if folks aren't keeping an eye out for it (and this article, like many personal experiences, indicate that people aren't yet). Having an AI voice in your ear, rapidly providing you answers in real time is something new; at least in terms of how easily accessible it is.

It's amazing to me that folks have the audacity to come to interviews like this. I think some candidates genuinely feel that it is a reasonable thing to do along the lines of stuffing their resumes with keywords to get through the various recruiter filters. It's like hey, everyone in baseball is doping, so I have to do it to keep up!

The behaviors are obvious once you've seen them before, but as an engineer and not a "talent acquisition" person, I feel deeply uncomfortable implying that some candidate I'm interviewing is lying or cheating, so it took me a bit to speak up about it.

These types of articles need to continue to come out and the conversation elevated, if just to save some poor devs hours of interviews with candidates who were able to bluff their way through the less technical initial conversations.

Comments URL: https://news.ycombinator.com/item?id=13041257

Points: 6

# Comments: 0

I don't think I could've made it this far by diving in head first. Like it or not, I have to get work done, and when I couldn't get a motion to work right or didnt know the best way to do something, I could fall back on sublimes regular tools.

Comments URL: https://news.ycombinator.com/item?id=6306084

Points: 2

# Comments: 0

The value, to me, is that I can create true modules with html, css, and js that are scoped to ONLY inside the tag I design (finally my css won't step on other css and I won't have to use unnecessary selectors to ensure that), and it will all be handled by the browser; no libraries needed (if web components becomes standardized of course).

For now, google and mozilla are creating polyfills to add this functionality because they want people to get onboard with the web component thing so that it will drive adoption and a consensus on how it should work in the final spec. I definitely recommend doing some research on the pieces and how they fit together because they are, at the least, intriguing and possibly the somewhat distant future of web application development.

http://www.polymer-project.org/faq.html

http://www.w3.org/TR/2013/WD-components-intro-20130606/

http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...

http://www.html5rocks.com/en/tutorials/webcomponents/templat...

However, if I simply ask "why", I find out that (90% of the time), they just want the logo to be more prominent. As a graphic designer, I know a number of tricks to make elements more visible aside from making them bigger. At this point I can offer a variety of solutions that increase visibility while maintaining the balance of the original design.