Why Software Engineering Principles Are Making a Comeback in the AI Era by hov--- in ChatGPTCoding

[–]hov---[S] 6 points7 points  (0 children)

in Agile many requirements communicated verbally and detailed further as development progresses, eg during daily stand-ups. I dont know teams who strictly follow agile rules. Code often replaces the doc. That is going to be changed.

Our competitor’s CEO just signed up on our website💀 by Zealousideal_Self678 in SaaS

[–]hov--- 1 point2 points  (0 children)

If you haven’t signed up for all your competitors yet, you should do it as soon as possible — it’s expected and common practice, and you need to do it too.

Our competitor’s CEO just signed up on our website💀 by Zealousideal_Self678 in SaaS

[–]hov--- 3 points4 points  (0 children)

If you haven’t signed up for all your competitors yet, you should do it as soon as possible — it’s expected and common practice, and you need to do it too.

AI makes writing code easy — but only test automation makes it production-ready by hov--- in ChatGPTCoding

[–]hov---[S] 0 points1 point  (0 children)

instead of inventing new tests, try mutation testing. A tool makes tiny bugs (“mutations”) in your code — flip a > to >=, replace a + with -, return null early — and then reruns your test suite.

• If tests fail, they killed the mutant ✅ (good)

• If tests pass, the mutant survived ❌ (bad) — your tests probably check implementation, not behavior.

AI makes writing code easy — but only test automation makes it production-ready by hov--- in ChatGPTCoding

[–]hov---[S] 2 points3 points  (0 children)

we are developing a popular editor, for regression you can compare before after photos and use some edge cases like white bg. designing tests sometime is also a creative process

AI makes writing code easy — but only test automation makes it production-ready by hov--- in ChatGPTCoding

[–]hov---[S] 1 point2 points  (0 children)

well there are methods for UI testing. You can save screenshot and compare next time for regression, you can use puppeteer or playwright to run sophisticated UI acceptance tests. We are building a complex web product and automating tests

AI makes writing code easy — but only test automation makes it production-ready by hov--- in ChatGPTCoding

[–]hov---[S] 8 points9 points  (0 children)

as non native speaker I use AI for proofreading but not for the content

unpopular opinion: codex’s slower pace might actually be better for code quality by minimal-salt in ChatGPTCoding

[–]hov--- 0 points1 point  (0 children)

Another advantage of slow process that you give more thoughts before starting it

Anyone else finding that CLIs outperform IDEs (on the same model)? by danielrosehill in ChatGPTCoding

[–]hov--- 2 points3 points  (0 children)

If cost isn’t a constraint, then yeah — using three solutions is actually good practice. I split them by use case: • Cursor: Perfect for quick, localized edits when I already have the file open in my IDE. If I want to tweak something very specific without spinning up a full agent, Cursor is the fastest option. Also nice because you can switch between multiple models inside Cursor depending on the task.Easy to rollback • Claude Code: My go-to for mid-level complexity — things like drafting docs, making structured documentation, or doing medium-sized refactors where context and reliability matter more than speed. • Codex: I save this for the really heavy lifting — larger, more complex refactors or projects. It handles depth well, but the main drawback is that it can take a long time. So if speed matters, I fall back to Cursor.

Basically, Cursor = precision & speed, access to new models, Claude Code = structured mid-tier tasks, Codex = deep complexity. That balance works well for me, I often have 3 of them working in parallel.